GCC Bugzilla Bug 14161

Compiling eCOS, compilation succesful, but one of the constructors is invoked
in 
wrong order (Cyg_Mempool_dlmalloc cygmem_pool_heap1), the same code compiled 
uing GCC3.2 constructors invoked in right order.

>arm-elf-gcc -v
Reading specs from
/ecos-e/Tools/arm-elf-cygwin/bin/../lib/gcc/arm-elf/3.4.0/spe
cs
Configured with: /c/Src/gcc-3.4-20040215/configure --target=arm-elf
--prefix=/c/
gnutools.arm --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib
--with-gxx-include-dir=/gnutools.arm/arm-elf/include -v : (reconfigured)
/c/Src/
gcc-3.4-20040215/configure --target=arm-elf --prefix=/c/gnutools.arm
--enable-la
nguages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib
--with-gxx-include-dir=/
gnutools.arm/arm-elf/include -v
Thread model: single
gcc version 3.4.0 20040216 (prerelease)


How-To-Repeat:
Try to compile the eCOS kernel using GCC3.4.

We cannot do anything without a testcase.  Can you supply one besides say
download eCOS.

(In reply to comment #1)
> We cannot do anything without a testcase.  Can you supply one besides say 
download eCOS.

I can supply compiled only; do not assembled files generated using GCC3.4 and 
GCC3.2. Problem is with (init_priority) atribute, it doesn't work correcly.

I think that problem is with generated function name 
(_ZN12Cyg_Mempolt2I35Cyg_Mempool_dlmalloc_ImplementationEC1EPhij) 

vs (Z41__static_initialization_and_destruction_0ii) in GCC3.2




GCC3.2:
-------
	.file	"heaps.cxx"
	.section	.debug_abbrev,"",%progbits
.Ldebug_abbrev0:
	.section	.debug_info,"",%progbits
.Ldebug_info0:
	.section	.debug_line,"",%progbits
.Ldebug_line0:
	.text
.Ltext0:
	.global	cygmem_pool_heap1
	.section	.bss.cygmem_pool_heap1,"aw",%nobits
	.global	cygmem_pool_heap1
	.align	2
	.type	cygmem_pool_heap1,object
	.size	cygmem_pool_heap1,1044
cygmem_pool_heap1:
	.space	1044
	.global	cygmem_memalloc_heaps
	.section	.data.cygmem_memalloc_heaps,"aw",%progbits
	.align	2
	.type	cygmem_memalloc_heaps,object
	.size	cygmem_memalloc_heaps,8
cygmem_memalloc_heaps:
	.word	cygmem_pool_heap1
	.word	0
	.section	.text._Z41__static_initialization_and_destruction_0ii,"ax",%
progbits
	.align	2
	.type	_Z41__static_initialization_and_destruction_0ii,function
_Z41__static_initialization_and_destruction_0ii:
.LFB1:
.LSM0:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 1, uses_anonymous_args = 0
	mov	ip, sp
.LCFI0:
	stmfd	sp!, {r4, r5, r6, fp, ip, lr, pc}
.LCFI1:


...

GCC3.4:
-------

	.file	"heaps.cxx"
	.section	.debug_abbrev,"",%progbits
.Ldebug_abbrev0:
	.section	.debug_info,"",%progbits
.Ldebug_info0:
	.section	.debug_line,"",%progbits
.Ldebug_line0:
	.text
.Ltext0:
	.section	.ctors,"aw",%progbits
	.align	2
	.word	_GLOBAL__I_cygmem_pool_heap1
	.section	.dtors,"aw",%progbits
	.align	2
	.word	_GLOBAL__D_cygmem_pool_heap1
	.global	cygmem_memalloc_heaps
	.section	.data.cygmem_memalloc_heaps,"aw",%progbits
	.align	2
	.type	cygmem_memalloc_heaps, %object
	.size	cygmem_memalloc_heaps, 8
cygmem_memalloc_heaps:
	.word	cygmem_pool_heap1
	.word	0
	.global	cygmem_pool_heap1
	.section	.bss.cygmem_pool_heap1,"aw",%nobits
	.align	2
	.type	cygmem_pool_heap1, %object
	.size	cygmem_pool_heap1, 1044
cygmem_pool_heap1:
	.space	1044
	.section	.gnu.linkonce.t.
_ZN12Cyg_Mempolt2I35Cyg_Mempool_dlmalloc_ImplementationEC1EPhij,"ax",%progbits
	.align	2
	.weak	_ZN12Cyg_Mempolt2I35Cyg_Mempool_dlmalloc_ImplementationEC1EPhij
	.type	_ZN12Cyg_Mempolt2I35Cyg_Mempool_dlmalloc_ImplementationEC1EPhij, %
function
_ZN12Cyg_Mempolt2I35Cyg_Mempool_dlmalloc_ImplementationEC1EPhij:
.LFB185:
	.file 1 
"/ecos-c/Arm/System/ecos-ram-eb40a_install/include/cyg/memalloc/mempolt2.inl"
	.loc 1 73 0
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 1, uses_anonymous_args = 0
	mov	ip, sp
.LCFI0:
	stmfd	sp!, {r4, fp, ip, lr, pc}
.LCFI1:

>We cannot do anything without a testcase.  Can you supply one besides say 
>download eCOS

There is testcase:
---------------------

#include <iostream>

struct P
{
P (int i) { std::cout << "Doing " << i << std::endl; }
};



static P first(900) __attribute__ ((init_priority (900)));
static P second(300) __attribute__ ((init_priority (300)));
static P third(3) __attribute__ ((init_priority (3)));

int main ()
{
std::cout << "Blah." << std::endl;
return 0;
}

C>arm-elf-g++ test.cxx
test.cxx:10: warning: attributes after parenthesized initializer ignored
test.cxx:11: warning: attributes after parenthesized initializer ignored
test.cxx:12: warning: attributes after parenthesized initializer ignored

So attributes are ignored, should they be ignored or not?

This works though (but does not compile with anything before 3.4.0):
#include <iostream>
#include <stdio.h>

struct P
{
P (int i) { printf("Doing %d\n", i ); }
};
static P first __attribute__ ((init_priority (900))) (900) ;
static P second __attribute__ ((init_priority (300))) (300);
static P third __attribute__ ((init_priority (200))) (3);

int main ()
{
std::cout << "Blah." << std::endl;
return 0;
}

>This works though (but does not compile with anything before 3.4.0)

Yes, but why GCC3.4 doesn't suport old way of defining attributes ????

The change to ignore the attributes was intentional.

See a message I posted to the mailing lists on 2002-08-13:

http://gcc.gnu.org/ml/gcc/2002-08/msg00792.html