Patch for PIC mode on IA64 (fixes libgomp failures on HP-UX)

[Steve Ellcey]

On Fri, 2008-08-01 at 09:01 +0200, Paolo Bonzini wrote:
> > What I don't quite understand is why you deem it better to change GCC
> > than to change Libtool.  I assume your change pessimizes TLS with
> > static libgomp?  If so, does anybody care about that (asking because
> > I have no idea)?
> 
> It pessimizes TLS for all static libraries and for all executables not 
> compiled with PIE.  I don't know on IA64 but the penalty on x86 would be 
> very heavy.  I would patch libtool instead.
> 
> Paolo

I don't know how much of a penalty it is.  HP ships most of its system
libraries as shared only and the linker prefers shared libraries to
archive ones so the performance of archive libraries is less important.
It looks like linux still ships everything as archive and shared.  As
for executables one can still specify the desired thread model for those
when building.

Since HP and Intel both default to the dynamic thread model, I can't
imagine the performance hit is too bad.  A more interesting possible
performance hit may be with inlining.  With my patch I noticed that some
ipa tests like gcc.dg/ipa/ipa-1.c started failing.  The tests are
skipped if -fpic is explicitly given and they fail with my patch since
my patch turns on pic implicitly.  But I am not sure I understand why
they fail with -fpic.  The tests have main calling f calling g and, with
no pic flag specified, g is inlined into f.  With -fpic this inlining
does not happen and the comment in PR 25442 (listed in the dg-skip-if
statement) says "These tests should be skipped for -fPIC/-fpic as the
functions can be overridden".  Can they?  They are not weak functions.
How could f call a different version of g if there is a g in the same
compilation unit?

Steve Ellcey
sje@cup.hp.com