Bug 14161 - [3.4/4.0 Regression] Constructors invoking priority problem
Summary: [3.4/4.0 Regression] Constructors invoking priority problem
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2004-02-16 15:44 UTC by Krzysztof Czyz
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: i686-pc-cygwin
Target: arm-elf
Build:
Known to work: 3.3.3
Known to fail: 3.4.0 4.0.0
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Krzysztof Czyz 2004-02-16 15:44:46 UTC
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.
Comment 1 Andrew Pinski 2004-02-16 15:49:29 UTC
We cannot do anything without a testcase.  Can you supply one besides say download eCOS.
Comment 2 Krzysztof Czyz 2004-02-16 16:07:32 UTC
(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:

Comment 3 Krzysztof Czyz 2004-02-16 17:35:57 UTC
>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?
Comment 4 Andrew Pinski 2004-02-16 18:32:34 UTC
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;
}
Comment 5 Krzysztof Czyz 2004-02-16 19:11:41 UTC
>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 ????

Comment 6 Mark Mitchell 2004-02-20 07:13:32 UTC
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