This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]: Fix PR middle-end/6123, cleanup defining __pic__/__PIC__
On Tue, Apr 06, 2004 at 12:05:04PM -0700, Richard Henderson wrote:
> On Sat, Apr 03, 2004 at 09:15:11PM +0930, Alan Modra wrote:
> > On most other targets, -fpic, ie. flag_pic, means two things:
> > a) generate PIC code, and
> > b) generate code suitable for ELF shared libraries.
> > I'll not argue the wisdom of -fpic meaning two things, but that's just
> > how things evolved. On PowerPC64, code generation is always PIC, but we
> > don't want the overhead of meeting shared library run-time symbol
> > resolution requirements when generating application code. Thus, we
> > don't want to set flag_pic all the time.
>
> Indeed, the same is true for Alpha as well.
>
> > Let me do some research on which of the two meanings of __PIC__ is
> > most important. If it turns out that __PIC__ is mostly used to detect
> > compilation in shared library mode, then the current PowerPC64 behaviour
> > is wrong.
>
> I very much suspect that absolutely no one cares about (a) and
> that *all* existing uses of __PIC__ are actually checking for (b).
I grepped through the entire slackware linux source base for occurrences
of __PIC__, and found that all those that might affect PowerPC64 were
testing for (b). There were only three occurrences, all in glibc! Many
more for x86 which I didn't pay much attention to, but the few I did
look at were actually testing for (a). This isn't so surprising, since
on x86 we want different assembly for PIC code, regardless of whether
PIC code is for shared libs (most likely) or otherwise. OTOH, the
only sensible test of __PIC__ on PowerPC64 can be for (b), since we
are (a) all the time.
Because we currently define __PIC__ all the time, the three occurrences
affecting PowerPC64 Linux result in missed optimizations for non-shared
lib code.
This suggests that powerpc64-linux-gcc should only define __PIC__ when
-fPIC is given, and that Kaveh's patch is OK.
--
Alan Modra
IBM OzLabs - Linux Technology Centre