glibc 2.15 won't build with GCC 4.7ish on ppc64: -fno-inline-functions is no longer enough to prevent call_gmon_start from being inlined into initfini.c's _init, as required by glibc's somewhat convoluted compilation of initfini.c into crt*.o. As a result of the inlining, a branch and its target label end up in separate object files, after the compiler's assembly output is broken up in pieces.
I suppose this could be easily worked around in glibc, by using attribute noinline (and noclone, for good measure, for partial inlining of the gmon_start undef-weak test would be just as damaging), or compiling sysdeps/generic/initfini.c with -fno-inline-functions-called-once (if available), and perhaps also -fno-inline-small-functions, -fno-indirect-inlining and -fno-partial-inlining, with room for whatever other options we GCC developers come up with to control other cases or kinds of inlining. I'm a bit surprised that -fno-inline-functions doesn't imply all of these, as long as they're not specified explicitly. IMHO it should. I'm also surprised that some parts of GCC appear to assume that -fno-inline was supposed to behave that way, preventing any inlining whatsoever. Grepping for flag_no_inline shows some hits that appear to indicate some confusion as to its meaning. To make matters worse for glibc, it appears that at least -finline-functions-called-once is already present in earlier releases of GCC, which means we might have no choice but to bite the bullet and use this option if it's available, even though I have no evidence that the implementation controlled by the option caused any problems to glibc's initfini compilation in already-released versions of GCC. So, where do we go from here? Is there any reason why glibc doesn't use the noinline attribute in sysdeps/generic/initfini.c, or for glibc not to auto-detect -fno-inline-functions-called-once et al and use them in addition to -fno-inline-functions to compile initfini.c? As for GCC, shouldn't we aim at providing a stable, reliable option that prevents inlining of functions not marked always_inline, regardless of special cases and exceptions to the general inlining rules we might come up with in the future? Also, shouldn't the implementation of -finline/-fno-inline be adjusted to match the documentation, and have flag_no_inline_functions become what we test for as flag_no_inline in some functions that make decisions about whether or not to perform inlining? Thanks in advance for feedback and suggestions, -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
