[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #21 from ajd at gentrack dot com 2007-10-19 01:44 --- Created an attachment (id=14372) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14372&action=view) support -blazy, add option to disable I suggest exportinitfini_flag is enabled by default or atleast for the build of libstdc++.a and libgcc_s.a. It should have minimal impact/risk. initdependents_flag has risk/impact attached. You may want to reverse the default. My case for having it on by default: To use exceptions within global constructors a module needs to be linked with initdependents_flag enabled. I believe there are other functions in libstdc++ that depend on initialization order. I do not have specifics. Assuming AIX was the only OS that works this way, it allows removal of these types of workarounds: http://gcc.gnu.org/ml/libstdc++/2001-01/msg00369.html -- ajd at gentrack dot com changed: What|Removed |Added Attachment #14327|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #19 from ajd at gentrack dot com 2007-10-14 21:39 --- (In reply to comment #18) > Do you plan to support lazy binding as well? Do you mean -blazy? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #17 from ajd at gentrack dot com 2007-10-10 04:04 --- (In reply to comment #16) > lib1.a depends on lib2.a > main depends on lib1.a, but does not explicitly link with lib2.a main initializes what it is explicitly linked against. lib1 initializes lib2 before it initializes itself. -- See attached test_init_order.cpp: $ # -- create lib2 $ g++ -shared -o lib2.a -D LIBNAME=LIB2 test_init_order.cpp $ # -- create lib1 depends on lib2 $ g++ -shared -L. -l2 -o lib1.a -D LIBNAME=LIB1 -DCALLEE=LIB2 test_init_order.cpp $ # -- hide lib2 from main $ mv lib2.a /tmp/lib2.hide $ # -- link main against lib1 $ g++ -L. -l1 -o m -D LIBNAME=main -DCALLEE=LIB1 test_init_order.cpp $ # -- unhide lib2 $ mv /tmp/lib2.hide lib2.a $ ./m LIB2_init LIB1_init main_init main() LIB1() LIB2() main_fini LIB1_fini LIB2_fini $ # -- replace lib1 with a library that doesn't depend on lib2 $ # -- leave main alone $ g++ -shared -o lib1.a -D LIBNAME=LIB1 test_init_order.cpp $ /usr/local/bin/sudo slibclean $ ./m LIB1_init main_init main() LIB1() main_fini LIB1_fini -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #15 from ajd at gentrack dot com 2007-10-09 21:44 --- (In reply to comment #14) > You seem to want to have the main program run the share library constructors. > That's a no-no. And decide at link-time. Double no-no. Do you mind explaining a situation that won't work because of this? The the following work should work as -binitfini is still used: - LDR_PRELOAD - libraries loaded by dlopen at runtime - executables linked by xlc loading libraries compiled by gcc If main was directly linked against lib1.a: - lib1.a can add/remove dependencies against other libraries. - lib1.a can change it's constructors. - lib1.a can be resolved to a completely different library as long as the replacement contains __GLOBAL__FI_lib1. The two situations I can identify that won't work are if the replacement lib1.a was renamed or was compiled by xlc. I can look at resolving these if they're the only problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #13 from ajd at gentrack dot com 2007-10-09 20:06 --- (In reply to comment #9) > A solution within GCC is very complicated. Have you looked at the suggested patch? If you could point out any concerns/faults, I could have another try at it. XLC has it's own solution implemented within the compiler / support libraries. So it seems the loader behaviour only impacts gcc. It could be seen as a deficiency in the gcc compiler / support libraries. (In reply to comment #11) > The problem *could* be solved in GCC, so it probably is worth retaining the > PR. Should I raise a separate PR for throw_failure.cpp? I lumped them together because I figured it was the same root cause. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #7 from ajd at gentrack dot com 2007-10-09 02:43 --- Introduced here: http://gcc.gnu.org/ml/gcc-patches/2004-03/msg00616.html My suggested fix is co-incidentally reversing some of that patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #5 from ajd at gentrack dot com 2007-10-09 01:55 --- Please reconsider. This is about initialization order between shared libraries. Not betweeen objects within a library. This works on atleast Linux, Windows, Solaris, HPUX, Tru64. The testcase throw_failure.cpp shows that libgcc/libstdc++ depend on this initialization order. So if the initialization order is really unspecified, then libgcc/libstdc++ have a bug. -- ajd at gentrack dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #4 from ajd at gentrack dot com 2007-10-09 01:50 --- Created an attachment (id=14327) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14327&action=view) suggested solution The attached patch is a suggested solution to this problem. It calls the __GLOBAL__FI_... functions (which call the C++ constructors) of linked libraries before calling the constructors of the current module. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #3 from ajd at gentrack dot com 2007-10-09 01:49 --- Created an attachment (id=14326) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14326&action=view) shows fallout from this (throw does not work in a global constructor as libstdc++ and libgcc_s constructors have not been run). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug target/33704] AIX runs c++ constructors in incorrect order
--- Comment #2 from ajd at gentrack dot com 2007-10-09 01:48 --- Created an attachment (id=14325) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14325&action=view) testcase shows constructors running in incorrect order Compile like: g++ -shared -o liba1.a -D LIBNAME=LIB1 test_init_order.cpp g++ -shared -L. -la1 -o liba2.a -D LIBNAME=LIB2 -DCALLEE=LIB1 test_init_order.cpp g++ -shared -L. -la2 -o liba3.a -D LIBNAME=LIB3 -DCALLEE=LIB2 test_init_order.cpp g++ -L. -la3 -o m -D LIBNAME=main -DCALLEE=LIB3 test_init_order.cpp Creates libraries dependencies like: m -> LIB3 -> LIB2 -> LIB1 Expected output is: LIB1_init LIB2_init LIB3_init main_init main() LIB3() LIB2() LIB1() main_fini LIB3_fini LIB2_fini LIB1_fini Actual output is: main_init LIB3_init LIB2_init LIB1_init main() LIB3() LIB2() LIB1() LIB1_fini LIB2_fini LIB3_fini main_fini -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug target/33704] New: AIX runs c++ constructors in incorrect order
On AIX global C++ constructors are run in the order that modules are loaded at runtime. It does not take into account dependencies between the modules. e.g. if MAIN depends on LIB1, the global constructors in MAIN are run before the global constructors for LIB1. It is expected that global C++ constructors in a linked library are run before constructors in modules that depend on these libraries. e.g. if MAIN depends on LIB1, it is expected that constructors in LIB1 are run before the constructors for MAIN. -- Summary: AIX runs c++ constructors in incorrect order Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ajd at gentrack dot com GCC target triplet: powerpc-ibm-aix5.2.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
[Bug target/33548] Core dump on HPUX
--- Comment #1 from ajd at gentrack dot com 2007-10-01 01:58 --- Compile with -Wl,-Z and it succeeds: gcc-4.1.2/bin/gcc -mlp64 pam_test.c -lpam -o pt -Wl,-Z It appears libpam on hpux requires -Z. It was removed here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00542.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33548
[Bug c++/20571] New: -Wswitch incorrectly outputs warning on ranges (regression from 3.4)
Test program:
enum fred
{
apple,
orange,
fruit_1,
fruit_2,
fruit_3,
};
int xx()
{
fred e;
switch (e) {
case apple:
;
case orange:
;
case fruit_1 ... fruit_3:
;
}
}
gcc 3.4 correctly accepts this code without warning.
gcc 4.0 (of Mar 17 18:06 UTC) incorrectly generates a warning.
$ /opt/gcc-3.4/bin/g++ -Wswitch -c a1.cpp
$ /opt/gcc-4.0.pre/bin/g++ -Wswitch -c a1.cpp
a1.cpp: In function 'int xx()':
a1.cpp:13: warning: enumeration value 'fruit_2' not handled in switch
a1.cpp:13: warning: enumeration value 'fruit_3' not handled in switch
--
Summary: -Wswitch incorrectly outputs warning on ranges
(regression from 3.4)
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ajd at gentrack dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20571
[Bug c++/18214] New: Wrong code for function call involving copy constuctor
Configured with: /home/ajd/gcc-3.4.2/configure --prefix=/opt/gcc-3.4.2 --
enable-languages=c,c++ --enable-threads=posix --with-gnu-as --without-gnu-ld --
with-as=/usr/local/bin/as
Thread model: posix
gcc version 3.4.2
Also reproduced on 3.4.0 and 3.3.2.
The following code segfaults at runtime.
Compiling without any options or optimization (ILP32 mode).
$ g++ test.cpp
$ ./a.out
Memory fault(coredump)
The fault is on the line 'start = src.m_s;', but I believe the problem is in
the argument passing to change.
-
class var
{
public:
var();
var(const var& copy);
~var();
char *m_s;
public:
};
void change(var src, var from)
{
char *start;
start = src.m_s;
}
int main()
{
var x;
change(x, x);
return 0;
}
var::~var()
{
}
var::var(const var& r)
{
m_s = "UUU";
}
var::var()
{
m_s = "UUU";
}
-
The following assembly is produced for the call to change:
adds r14 = -48, r35
;;
mov r37 = r14
adds r15 = -64, r35
;;
mov r38 = r15
[.LEHB1:]
br.call.sptk.many b0 = _ZN3varC1ERKS_#
[.LEHE1:]
mov r1 = r36
adds r15 = -48, r35
adds r14 = -8, r35
;;
st8 [r14] = r15
adds r14 = -32, r35
;;
mov r37 = r14
adds r14 = -64, r35
;;
mov r38 = r14
[.LEHB2:]
br.call.sptk.many b0 = _ZN3varC1ERKS_#
mov r1 = r36
adds r14 = -32, r35
adds r15 = -4, r35
;;
ld4 r37 = [r15]
mov r38 = r14
br.call.sptk.many b0 = _Z6change3varS_#
mov r1 = r36
The last 4 lines is where it appears to go wrong.
EG: it is loading from memory at [r15] which is uninitialized.
--
Summary: Wrong code for function call involving copy constuctor
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ajd at gentrack dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ia64-hp-hpux11.23
GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18214
