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: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>
- Cc: gcc-patches at gcc dot gnu dot org, wilson at tuliptree dot org
- Date: Thu, 31 Jul 2008 11:20:16 -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>
- Reply-to: sje at cup dot hp dot com
On Thu, 2008-07-31 at 20:04 +0200, Ralf Wildenhues wrote:
> I'm not quite sure I understand what your patch does, but are you saying
> that Libtool should be changed in any way?
Libtool doesn't have to be changed although it could be. Libtool, right
now, is saying that we don't need to specify -fpic when compiling PIC
code on IA64 HP-UX because that is the default.
The problem is that IA64 is only *almost* generating PIC code by
default. All of the instructions are PIC but GCC is using different TLS
(thread local storage) models depending on whether or not the -fpic flag
is explicitly given. This patch addresses the problem by making GCC
really truly generate PIC code as the default by having GCC default to
the same TLS model with or without the -fpic flag. Thus the current
Libtool behaviour would be correct for IA64 HP-UX after applying this
patch to GCC.
If we apply this GCC patch then the -fpic flag isn't needed for IA64
Linux either but Libtool is currently passing that to the IA64 Linux GCC
compiler when generating pic code on that platform. This could be
changed but wouldn't have to be.
If we don't apply this patch we could address the problem by changing
libtool to use -fpic when it calls the IA64 HP-UX compiler but I am
proposing that we change the compiler and leave libtool alone.
Did that help or did I just confuse things more?
Steve Ellcey
sje@cup.hp.com