This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] -fpie/-fPIE/-pie GCC support
On Mon, 2 Jun 2003, Jakub Jelinek wrote:
> There are way more difference between -fno-pic and -fpic than between
> -fpic and -fpie and I haven't ever seen code which would use __pic__
> or __PIC__ to determine if a locally defined non-static variable
> can be accessed through @GOTOFF or whether some function can be inlined at
> -O3. __PIC__/__pic__ is used for things like saving/restoring pic register
It's just that the confusion about -fPIC meaning PIC versus meaning
compiling for a shared library has come up often enough on the GCC lists
that I wondered what users of the defines were expecting them to mean.
If they are generally using them just to mean PIC then that's fine.
With the flag_pic / flag_shlib separation, should platforms on which code
is always or by default position-independent be setting flag_pic by
default?
> __PIC__ and __pic__ definitions are also target dependent, so IMHO it cannot
> be done globally but has to be kept in target headers.
Are they really target-dependent, when there is a central flag_pic?
__ELF__ was centralised to elfos.h and documented, what would break if
__PIC__ and __pic__ were centrally defined conditional on flag_pic, and
documented as target-independent?
> The __PIC__/__pic__ definitions should be done in TARGET_OS_CPP_BUILTINS
> and similar macros, like it is done for most GCC targets these days
> (for them I did not have to do these changes, they already do
> things like:
But given this point it seems reasonable for centralising these
definitions to be a separate cleanup for someone to do in any case.
--
Joseph S. Myers
jsm28@cam.ac.uk