possible patch

[Benjamin Kosnik]

> 
> I'm thinking of a patch to GLIBCPP_CHECK_COMPILER_VERSION ("for g++ that
> supports new inlining mechanism").  The idea is that if the compiler can't
> do the new inlining, it shouldn't warn about not being able to inline code.
> Or at least not die if it does the warning.

Yeah. Great idea.

> In addition to emitting '-O2' vs '' it would also add -Wno-inline for
> only those files which are currently dying on the lack of the tree-based
> inliner for 2.95.2.  (Alternatively, it could turn off -Werror and still
> do the warning.)

I'd rather the warning but not the error, but whatever. Whatever seems best.

> Currently I have a local patch which removes -Werror altogether (not
> just for those few files) if using g++ <2.96, but that's kind of drastic,
> since -Werror is otherwise useful.
> 
> Thoughts?

I'm sold on the idea of using -Werror. It keeps us honest... and it's 
helped find a lot of weirdnesses in both the compiler and the v3 
codebase that would have otherwise been ignored, or found later.

> 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?

-O2 is where member functions start to get inlined. It's where the 
tree-based inliner in gcc-2.96 is activated. I don't think this happening 
at -O2 instead of -O3 is especially new -- it's just that what can be 
inlined is drastically increased with the new inliner. All of this may 
be wrong however, perhaps Mark or Jason might know more. It's a blessing 
for those using the new compiler, and a curse for those trying to synch 
between the 2.95/2.96 versions. 

-benjamin