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 attachment 13288 [details] Simple Script which will build the original C source Simple Script which will build the original C source
Created attachment 13289 [details] original source
Created attachment 13290 [details] 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.