This is the mail archive of the 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

Thanks in advance for feedback and suggestions,

Alexandre Oliva, freedom fighter
You must be the change you wish to see in the world. -- Gandhi
Be Free! --   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]