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__
> From: David Edelsohn <dje@watson.ibm.com>
>
> > 4. In rs6000/linux64.h, it hardcodes just __PIC__=1.
> >
> > However for #4 on powerpc64-unknown-linux-gnu, the default case does
> > not define __PIC__ with my patch, so this is a change. I'm not sure
> > why powerpc64 wants only __PIC__ hardcoded but not __pic__ and why
> > it's different from regular powerpc. Perhaps there's something wrong
> > here. (?)
>
> PPC64 Linux always is PIC, so this patch is wrong.
>
> If targets have well-establish meanings for __pic__ and __PIC__,
> GCC cannot impose it's own definition. This patch changes the behavior
> for multiple targets.
>
> I object to this patch.
> David
David,
Ok, your objection is noted. However you haven't made any attempt to
help arrive at a better solution. Perhaps you could be constructive
by commenting on these issues:
1. Explain why "PPC64 Linux always is PIC" without defining flag_pic
internally. This appears to be how Mips Linux handles itself.
Why the difference?
2. Explain why PPC64 Linux defines only __PIC__ and not __pic__.
(*Every* other target will define __pic__ also.) Can we safely
define __pic__ on this target? That alone will make it more
conforming.
3. Suggest a way to clean up the macro settings without hurting PPC64
Linux. Could be as simple as setting flag_pic=1 in the startup
routines for PPC64 Linux if that's appropriate. Other ideas come
to mind, but since you know more about this platform you are in a
better position to suggest the best alternative.
Now it's not yet clear whether the "established meanings" for __pic__
and __PIC__ are relevant, useful or even correct for the few targets
where changes in behavior might occur.
You've stated "PPC64 Linux always is PIC". Fine, I can easily rewite
the patch to consolidate every other platform and leave the behavior
of PPC64 Linux unchanged. That may or may not be correct or even good
for PPC64 Linux.
However, having these macros controlled in a consistent and
predictable way that users can rely on is worth pursuing. The current
situation is a complete mess as noted in my previous posting. So I
await your input on how to make progress.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu