possible patch

[Martin v. Loewis]

> Thoughts?

I wonder why library compilation needs -Winline at all. When you write
the library functions, you tag some as 'inline' based on your
experience with the C++ language, just as you make other
implementation decisions. It is not a serious problem if you mark some
functions with inline that can't be inlined.

Now, it may be good to occasionally check whether the compiler's
inline capabilities still match with the set of inline-declared
functions. This would go together with other performance checks, say
testing whether a frequently-used inline function is reduced to
reasonable size still on interesting targets, or what other
performance problems the library may have - ie. when you compile for
profiling. Warnings about not being able to inline really are not a
concern for the library users.

> Out of curiosity, I thought inlining wasn't performed until -O3?  I
> don't see -finline-functions being passed in.  Why do we only define
> -O2 for a g++ that "supports the new inlining mechanism"?  Did the
> inlining get moved down a number?

No. Please have a look at the documentation, in particular:

`-fno-inline'
     Don't pay attention to the `inline' keyword.  Normally this option
     is used to keep the compiler from expanding any functions inline.
     Note that if you are not optimizing, no functions can be expanded
     inline.

`-finline-functions'
     Integrate all simple functions into their callers.  The compiler
     heuristically decides which functions are simple enough to be worth
     integrating in this way.

     If all calls to a given function are integrated, and the function
     is declared `static', then the function is normally not output as
     assembler code in its own right.

So -f[no-]inline controls whether the inline keyword is honored (it
normally is, except for -O0), and -f[no-]inline-functions controls
whether functions are inlined regardless of that keyword (this is only
active at -O3).

Regards,
Martin