This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: HPPA constructor merge patch, PR middle-end/45388
- From: Steve Ellcey <sje at cup dot hp dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 6 Dec 2010 14:35:43 -0800 (PST)
- Subject: Re: HPPA constructor merge patch, PR middle-end/45388
On 09/28/2010 18:30 AM, Jan Hubicka wrote:
> > On 09/28/2010 08:36 AM, Jan Hubicka wrote:
> > > This is bit difficult to arrange with LTO. We produce at compile time the consturctor
> > > function with magic names, then at LTO time we want to produce single constructor function
> > > calling them all. We would need to guess on what name is the magic name (by same logic
> > > as what collect does) and rename function back.
> > > I can definitly implement it, but it seems more hackish than the collect2 side change.
> >
> > An alternative is that at compile time we emit
> >
> > _Z41__static_initialization_and_destruction_0ii
> >
> > to the intermediate code as the constructor, and
> >
> > GLOBAL__I__ZN2c12f6Ev calls
> >
> > to the object code calling _Z41. However, we don't emit
> > GLOBAL to the intermediate code at all. Thus when LTO
> > replaces the object files there's no trace of the original
> > GLOBAL function at all, and thus collect2 does not see it.
> > LTO will simply see _Z41 and call that function directly.
> >
> > This is not entirely different from the case in which we
> > have .ctor support -- it's not like we read in the piece
> > of the object code that contains the .ctor data. Just
> > consider the GLOBAL function object file data.
> >
> > This should be doable with a flag on the decl for GLOBAL
> > that indicates that it should not be serialized.
>
> Or we can just produce those collected global constructors after
> serialization. I will check...
>
> Honza
> >
> >
> > r~
Honza,
Have you looked into this any more? I haven't seen any follow up from
you since this email. This defect, PR middle-end/45388, is a P1 defect,
it breaks the hppa bootstrap, and it has been open for over a month. I
would like to see this fixed, or your patch reverted, before we release
4.6.
Steve Ellcey
sje@cup.hp.com