This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch for PIC mode on IA64 (fixes libgomp failures on HP-UX)
- From: Steve Ellcey <sje at cup dot hp dot com>
- To: Paolo Bonzini <bonzini at gnu dot org>
- Cc: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>, gcc-patches at gcc dot gnu dot org, wilson at tuliptree dot org
- Date: Fri, 01 Aug 2008 16:05:15 -0700
- Subject: Re: Patch for PIC mode on IA64 (fixes libgomp failures on HP-UX)
- References: <200807292022.m6TKMs423945@evrst7.cup.hp.com> <20080731180415.GC1908@ins.uni-bonn.de> <1217528416.29788.21.camel@hpsje.cup.hp.com> <20080731183049.GB6437@ins.uni-bonn.de> <4892B4BD.8050405@gnu.org> <1217621272.14771.27.camel@hpsje.cup.hp.com> <48937D37.6060502@gnu.org>
- Reply-to: sje at cup dot hp dot com
On Fri, 2008-08-01 at 23:16 +0200, Paolo Bonzini wrote:
> > Since HP and Intel both default to the dynamic thread model, I can't
> > imagine the performance hit is too bad.
>
> I don't know; as I said it is on x86 (so much that glibc has special
> tricks so that it can use the static thread model despite being a shared
> library).
HP-UX doesn't have a static libc, just a shared one so this isn't an
issue there. Linux does have a full set of system static libs though.
> > How could f call a different version of g if there is a g in the same
> > compilation unit?
>
> Functions in a shared library can always be overridden by the executable.
Huh, learn something new every day. Apparently HP wrote in some fine
print in it's HP-UX specific IA64 runtime standard saying it is OK to do
inlining and local symbol resolution in a shared library in order to get
around this optimization problem.
Changing libtool to use -fpic/-fPIC is starting to look like a better
option.
Steve Ellcey
sje@cup.hp.com