[Bug target/12413] 'symbol already defined' when building ICU 2.6 with Cygwin

["dannysmith at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12413



------- Additional Comments From dannysmith at gcc dot gnu dot org  2003-09-30 11:25 -------
Confirmed on mainline with i386-mingw32:  YADIB (YetAnotherDllImportBug).

The problem is that virtual tables are being marked as dllimport (that is as 
undefined symbols ) and than later, because of loss of the dllimport attribute 
from the containing class, they are emitted.

Why is the attribute being lost from the containing class? 

Because of redeclaration of the class without the attribute after initial 
definition.

If I comment out the unnecessary 'forward' declarations in the preprocessed 
source (ie, declarations that follow the the class deinition with dllimport 
attribute), like so:

2531,2532c2531,2532
< class Replaceable;
< class UnicodeString;
---
> // class Replaceable;
> // class UnicodeString;
2594,2596c2594,2596
< class Replaceable;
< class UnicodeString;
< class UnicodeSet;
---
> // class Replaceable;
> // class UnicodeString;
> // class UnicodeSet;
3598c3598
< class Replaceable;
---
> // class Replaceable;
3602,3603c3602,3603
< class UnicodeString;
< class UnicodeSet;
---
> // class UnicodeString;
> // class UnicodeSet;
3699,3702c3699,3702
< class UnicodeFunctor;
< class UnicodeString;
< class UnicodeMatcher;
< class UnicodeReplacer;
---
> // class UnicodeFunctor;
> // class UnicodeString;
> // class UnicodeMatcher;
> // class UnicodeReplacer;


the compilation succeeds without error.

Here is a reduced testcase, that shows the redeclaration problem, but without 
the vtable fallout

// redecl.C
struct __attribute__ ((dllimport)) 
DllClass1
{
  static int instances;
};

struct __attribute__ ((dllimport)) 
DllClass2
{
  static int instances;
};


// Use DllClass1 and so force it to be emitted now

int foo()
{
   return DllClass1::instances;
}

// re-declarations without dllimport attribute
struct DllClass1;
struct DllClass2;

int bar1()
{
   // DllClass1::instances is marked as dllimport
   return DllClass1::instances;
}

int bar2()
{
  // DllClass2::instances is not marked as dllimport
  return DllClass2::instances;
}
// end redecl.C

Here is the assembler output for above:

	.file	"redecl.C"
	.text
	.align 2
.globl __Z3foov
	.def	__Z3foov;	.scl	2;	.type	32;	.endef
__Z3foov:
	pushl	%ebp
	movl	%esp, %ebp
	movl	__imp___ZN9DllClass19instancesE, %eax
	movl	(%eax), %eax
	popl	%ebp
	ret
	.align 2
.globl __Z4bar1v
	.def	__Z4bar1v;	.scl	2;	.type	32;	.endef
__Z4bar1v:
	pushl	%ebp
	movl	%esp, %ebp
	movl	__imp___ZN9DllClass19instancesE, %eax
	movl	(%eax), %eax
	popl	%ebp
	ret
	.align 2
.globl __Z4bar2v
	.def	__Z4bar2v;	.scl	2;	.type	32;	.endef
__Z4bar2v:
	pushl	%ebp
	movl	%esp, %ebp
	movl	__ZN9DllClass29instancesE, %eax  <<< no _imp__ prefix
	popl	%ebp
	ret


Note that DllClass2::instances is not marked as a dllimport (no _imp__ prefix).

In the strmatch case submitted by the OP, the vtable data for some classes
had initially been marked as imported, but had not been been used before
redeclaration.  It appears that these vtable's are being treated as  both
externally defined and needing a local definition.

I initially thought that setting INTERFACE_ONLY and INTEFACE_KNOWN for 
dllimport'd classes might help here, but looking at the comments for 
MULTIPLE_SYMBOL_SPACES in i386/cygming.h and in cp/decl.c and decl2.c I'm not 
so sure.  

Danny