https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
--- Comment #23 from David Edelsohn ---
Author: dje
Date: Sat Nov 23 15:38:07 2013
New Revision: 205309
URL: http://gcc.gnu.org/viewcvs?rev=205309&root=gcc&view=rev
Log:
libgcc:
PR target/33704
* config/rs6000/aixinitfini.c: New file
--- Comment #22 from bkoz at gcc dot gnu dot org 2007-10-19 02:00 ---
> I believe there are other functions in libstdc++ that depend on initialization
> order. I do not have specifics.
Perhaps:
FAIL: 27_io/objects/char/6.cc execution test
FAIL: 27_io/objects/wchar_t/6.cc execution test
--- 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
--- Comment #20 from dje at gcc dot gnu dot org 2007-10-18 00:48 ---
Yes, effectively -blazy, because of AIX's loader semantics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
--- 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
--- Comment #18 from dje at gcc dot gnu dot org 2007-10-12 12:56 ---
I think your patch would be okay as an option. Do you plan to support lazy
binding as well?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
--- 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 it
--- Comment #16 from dje at gcc dot gnu dot org 2007-10-10 03:17 ---
lib1.a depends on lib2.a
main depends on lib1.a, but does not explicitly link with lib2.a
Your proposed solution requires that the link of main see all dependent
libraries.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- 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 beca
--- Comment #14 from dje at gcc dot gnu dot org 2007-10-09 21:10 ---
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. You essentially want
to behave like a static link.
If you look at the discussion
--- 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 implem
--- Comment #12 from bangerth at dealii dot org 2007-10-09 15:18 ---
(In reply to comment #11)
> The problem *could* be solved in GCC, so it probably is worth retaining the
> PR.
OK.
> AIX Brand is much more likely to respond to a customer requirement than a
> request from within IBM
--- Comment #11 from dje at gcc dot gnu dot org 2007-10-09 15:07 ---
The problem *could* be solved in GCC, so it probably is worth retaining the PR.
AIX Brand is much more likely to respond to a customer requirement than a
request from within IBM. When the problem affects a sale, IBM w
--- Comment #10 from bangerth at dealii dot org 2007-10-09 14:53 ---
If it's a request to improve the AIX linker, should we even keep this PR
open?
David, as a sidenote (because you're at IBM), this is the sort of thing that
makes AIX such an unpopular target to do development on. It ju
--- Comment #9 from dje at gcc dot gnu dot org 2007-10-09 12:50 ---
This is a long-standing issue about the way AIX loader behaves. AIX loader
implements breadth-first, not depth first. This is a difference from
SVR4-based systems. I believe that SVR4 does specify the ordeer. Look ab
--- Comment #8 from bangerth at dealii dot org 2007-10-09 03:43 ---
(In reply to comment #6)
> And the order is still undefined between them, does not matter if it is a
> shared library or otherwise.
It is true that the standard only talks about the order of initialization
within each t
--- 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
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-10-09 01:59 ---
And the order is still undefined between them, does not matter if it is a
shared library or otherwise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33704
--- 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
--- 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
--- 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 be
--- 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_
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-09 01:48 ---
It is not specificed which order of constructors are run between two different
Translation units.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
24 matches
Mail list logo
