GCC Bugzilla Bug 31362

gcc should never inline functions which have a 'section' attribute set
on them.

If the section is placed at a specific location in memory via a linker
script, then the function will not be placed into its correct address,
and the resultant executable is incorrect.

gcc 4.1.1 will inline static function at -O1 and -O2, but not -O0 and
-O3; this can be seen by compiling the attached test program at
various optimization levels.

    static int __attribute__((section(".special_section"))) 
    special_function_0(void)
    {
       return 0;
    }

    int __attribute__((section(".special_section"))) 
    special_function_1(void)
    {
       return 0;
    }

    int main(void)
    {
       special_function_0();
       special_function_1();
       return 0;
    }

Created an attachment (id=13288) [edit]
Simple Script which will build the original C source

Simple Script which will build the original C source

Created an attachment (id=13289) [edit]
original source

Created an attachment (id=13290) [edit]
preprocessed source

If it is incorrect to inline a function you should specify that with
__attribute__((noinline)), I don't see why in general inlining a function which
out of line copy is in a special section is wrong.

I'm going to argue that comment #4 is incorrect.

1.  This new behavior is a regression from previous versions of gcc.

2.  The 4.1.1 compiler gets it right at -O0 and -O3.  Previous
    versions of gcc which we've been using also get this right at all
    optimization levels.

3.  The function is 'static', not '__attribute__((inline))'.  The use
    of static doesn't implicitly give the optimizer permission to
    inline the function, it only declares the linkage to be
    'internal'.

    However, if the compiler determines that the function meets
    certain criteria, such as being static and not having its address
    taken, then it *can* inline it.

    These 'certain criteria' should be expanded to include changing
    the section of a function; if it's not in the default text
    section, it shouldn't be inlined.  (Of course, this shouldn't
    impact gcc's internal garbage collection mechanism of changing
    function & data sections).

In the actual implementation from which this test case was derived,
the function *must* reside at a specific location in memory, but due
to the inlining, it does not.  This causes failures in the
application.

<qoute>
In the actual implementation from which this test case was derived,
the function *must* reside at a specific location in memory, but due
to the inlining, it does not.  This causes failures in the
application.
</quote>

You should tell the compiler this.  This is exactly what we have the
noinline and the always_inline (for the opposite case) attributes for.

Note that 'inline' is a mere hint to the compiler, the compiler is free
to inline functions not marked as such if it is possible and looks profitable.
You could for example put a function in section .text.hot but of course still
want inlining if possible.

The behavior is not a regression really, as it is not documented that
the section attribute prevents inlining.  Overloading the section attribute
with this additional restriction does not look right.

Note that for your testcase even if you specify the noinline attribute the
function calls will be optimized away as the function calls do not have
side-effects.

Furthermore, 

   4.  By placing the code in a different section, I'm instructing the
       the compiler to *not* put it in '.text'.  By inlining it, it
       places it in '.text' despite my instructions.

We inline static functions used once (special_function_0 in your testcase)
starting with the tree inliner which appeared in 3.4.0.  So the "bug" is
present
in all releases starting from 3.4.0 and still present in mainline.

And now there is already an option to stop this inlining static functions
called once.
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-finline_002dfunctions_002dcalled_002donce-507

4.1.2 also inlines the other one, so that won't help.  Still noinline will.

I respectfully submit that I think you guys are missing the point.

    The problem isn't that the compiler is inlining functions which
    are called once, the problem is that the compiler is inlining a
    function which I told it not to put into the '.text' section.

I fully understand that there are many ways to make gcc *not* inline
the function (noinline attribute, not static, call more than once,
take it's address), and I've already done that.

If I tell gcc to place code or data into another section, then it
should do that -- always.

Why do you think sections are special?
GCC does not know if a section is special or not and it really should not know.

> Why do you think sections are special?
> GCC does not know if a section is special or not and it really should not know.

I don't necessarily think that sections are 'special', but since gcc
has the capability to change the section, it seems like it ought to
follow instructions.

If that's not convincing enough, let me quote from the gcc 'info' page
about function attributes:

     `section ("SECTION-NAME")'

          Normally, the compiler places the code it generates in the
          `text' section.  Sometimes, however, you need additional
          sections, or you need certain particular functions to appear
          in special sections.  The `section' attribute specifies that
          a function lives in a particular section.  For example, the
          declaration:

               extern void foobar (void) __attribute__ ((section ("bar")));

          puts the function `foobar' in the `bar' section.

          Some file formats do not support arbitrary sections so the
          `section' attribute is not available on all platforms.  If
          you need to map the entire contents of a module to a
          particular section, consider using the facilities of the
          linker instead.

I don't think that I can be more clear than this text -- placing an
__attribute__(section ("bar")) will place the attributed function into
the 'bar' section.

By inlining the function, it's *not* placing it into the 'bar'
section.

There are many reasons why a function might need to be placed into a
special section but those reasons are really moot since the
documentation of the compiler states exactly what the section attribute
is supposed to do.

FWIW, I agree with the OP. This will place a burden on users who work with
embedded systems such as the AVR. Special sections are sometimes needed in the
AVR to place code into a special bootloader area that gets relocated at link
time to a user defined address. Many times there is only a single function call
to the bootloader code. As the problem is described, there is a potential that
the bootloader call would be inlined, hence no longer properly in the section
that has to be relocated to a special address. Now the burden will be left to
the end user to figure out that they need to add noinline to work around a too
aggressive, and too stupid inliner.

You supposed to mark all functions which you don't want inlined as noinline. 
that is what the noinline attribute is there for.  The inliner is just too
smart that is all.  If you want a dumber inliner fine, but don't complain to us
when the inliner is not as good any more.

In response to comment #16:

I wouldn't call an inliner which inlines functions specifically marked as "do
not put this in '.text'" as 'smart'.  I'd use a more pejorative adjective, such
as 'broken' or 'dumb'.

Well, you can continue to waste your time arguing here instead of fixing your
code
with a few additions of noinline.

         'The `section' attribute specifies that
          a function lives in a particular section.'

this just says that the function (the out-of-line copy) lives in a particular
section.  It doesn't mention inlined copies of the function _body_.

I guess I need a bigger typeface because I don't see where it says
'(the out-of-line copy)'.

Or, perhaps, you've simply added that '(the out-of-line copy)'
annotation yourself because that's what the code currently does, and
because it suits your agenda.  I guess you also felt free to interpret
that it's ok to inline such functions, even though it doesn't say any
such thing, and even though it goes against exactly what the 'section'
attribute intends to do.

But, as you stated, it's a waste of my time, and you folks obviously
aren't going to treat this as a legitmate defect, so there's no point
in continuing this.