This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

-fno-inline-functions vs glibc's initfini


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]