Re: HPPA constructor merge patch, PR middle-end/45388

[John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>]

The attached change reverts commit r163443.  This commit broke
constructor/destructor handling on targets using the collect2
_GLOBAL_* mechanism (e.g., 32-bit hppa*-*-hpux*).

It has now been nearly four months since the commit was made and
no progress has been made in finding a fix along the lines discussed
below.  I believe the change should be reverted to provide an
incentive to fix the issue.

With the change in place, it causes approximately 155 g++, 74 obj-c++
and 5 libgomp fails.  Thus, it is time consuming to watch for new
regressions in test runs.

The reversion is clean.  Except for the changes to ipa.c, the commit
can be directly reverted.  For ipa.c, there were some subsequent
changes to the new code but no interaction between old and new.
At this time, the change can be easily restored if a solution to
the collect2 problem is found.

The reversion has been tested on hppa2.0w-hp-hpux11.11.  It fixes
all the fails introduced in r163443.  There is one regression:
gcc.dg/ipa/ctor-empty-1.c.  This is expected.  See
http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01017.html
for test results.

Ok to commit?

On Tue, 28 Sep 2010, 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~

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Attachment: r163443.d.1
Description: Text document