Re: [4.2 PATCH]: PRs 6123 & 18382, centralize defining __PIC__/__pic__

["Kaveh R. Ghazi" <ghazi at caipclassic dot rutgers dot edu>]

 > Not ok, because you're not preserving...
 > 
 > > -      if (flag_pic)			\
 > > -	 {							\
 > > -	   builtin_define ("__pic__");
 > > -\
 > > -	  if (flag_pic > 1)			\
 > > -	      builtin_define ("__PIC__");		\
 > > -	      }
 > > -\
 > 
 > ... this distinction between -fpic and -fPIC.
 > r~

Well, that was kind of the point.  We have several different
algorithms for deciding when to define __pic__ and/or __PIC__ and what
to define them to.

0.  Some targets do nothing.

1.  Many (most?) targets do this:
	builtin_define ("__PIC__");
	builtin_define ("__pic__");

2.  A couple of them do just this:
	builtin_define ("__PIC__");

3.  One target as you pointed out (m68k.h) does this:
      if (flag_pic)
       {
         builtin_define ("__pic__");
         if (flag_pic > 1)
           builtin_define ("__PIC__");
       }

4.  And a couple do this (or the equivalent):
      if (flag_pic == 1)
       {
         builtin_define ("__pic__=1");
         builtin_define ("__PIC__=1");
       }
      else if (flag_pic == 2)
       {
         builtin_define ("__pic__=2");
         builtin_define ("__PIC__=2");
       }


What I'm proposing is to standardize on one mechanism.  And that is
the last one (#4), which I implement as:

      builtin_define_with_int_value ("__pic__", flag_pic);
      builtin_define_with_int_value ("__PIC__", flag_pic);

This makes sure that both macros are defined but their value is 1 for
-fpic and 2 for -fPIC.  That preserves testing #ifdef __pic__ and also
testing #ifdef __PIC__ which is important for the vast majority which
follow algorithm #1.

However you can still check #if __PIC__ == 2 for a more fine grained
analysis if you're on a platforms which used to follow mechanism #3
and exposed the difference between -fpic and -fPIC.

IMHO, consistency is better than the jumble of (undocumented!!)
mechanisms we have now.



If you still object, then I can add a new target macro such as
TARGET_HANDLES_PIC_MACRO, and define it in m68k.h.  Then check it
before running the code in c-cppbuiltins.c.  But note that
m68k/linux.h would override that back to the default.  So we're really
only talking about non-linux m68k.

Would you prefer the TARGET_HANDLES_PIC_MACRO approach or is cross
platform consistency compelling enough to accept the original patch?

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu