This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
- From: "ccoutant at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 13 Dec 2010 20:41:52 +0000
- Subject: [Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
- Auto-submitted: auto-generated
- References: <bug-46770-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
Cary Coutant <ccoutant at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ccoutant at gcc dot gnu.org
--- Comment #52 from Cary Coutant <ccoutant at gcc dot gnu.org> 2010-12-13 20:41:46 UTC ---
(In reply to comment #51)
> > If gcc switches from .ctors to .init_array, it needs to make sure to generate
> > the constructors in forward order within the TU, rather than backwards order as
> > it does in the .ctors section. I didn't see anything in HJ's patch that does
> > that.
>
> It uses priority, instead of MAX_INIT_PRIORITY - priority, to generate
> NNNN for .init_arry.NNNN.
No, I was talking about order of constructors within a TU without using
priority. If you have static constructors for A then B in your source file, gcc
will output B's constructor before A's in the .ctors section, so that A's will
run first. Where does your patch reverse that to account for the fact that
.init_array sections are processed in forward order?