Re: __INLINING__ patch

[Doug Evans <dje at transmeta dot com>]

Jeffrey A Law writes:

 >   > The current "proper" way of compiling a file on gcc+glibc systems
 >   > with -fno-inline -O is to also pass -D__NO_STRING_INLINES.
 >   > -fno-inline should DTRT and -D__NO_STRING_INLINES shouldn't be
 >   > required (and you agree, right Ulrich?).
 >   > One way to do this is to define a macro that system libraries can then
 >   > key off of.  [One can of course turn it around and define the macro
 >   > when not inlining.]
 >   > 
 > Conceptually I've got no problem defining a macro or two to indicate that
 > we're performing inlining.  But I do think just defining __INLINING__ is a
 > poor choice since it does not indicate at all what kind of inlining the
 > compiler is performing.

Ok, sure.

 > It seems to me that we would want to be able to distinguish between the
 > case where the compiler is inlining because directives in the code
 > requested it and cases where the compiler is automatically inlining
 > anything it can.  That could be done by defining different values for
 > __INLINING__ or using two different names.

Dunno.  That's more than what's needed for the task at hand.
[being wary of the argument of not introducing unneeded "features"]

 > Similar changes also need to be installed into the language specific
 > drivers since C isn't the only language that can/should be able to use
 > this information.  Probably the quickest way to find the locations that
 > need updating is to grep OPTIMIZE */*specs*.

Maybe we can turn this around and say it's -fno-inline that is causing
the problems.  That's easy to key off of in specs files.  So how about
define __FOO__ if -fno-inline is specified, ignoring the value of -On
[you pick "FOO" so we avoid a round of "but SUCH_AND_SUCH is
ambiguous". :-) A straightforward example is __FNO_INLINE__.]
Would that work?