http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49653
--- Comment #11 from Gary Funck <gary at intrepid dot com> 2011-07-07 19:01:19 UTC --- Thanks for the additional info. I agree that it would be incorrect for the compiler to default to "extern" if it chooses not to inline the function (I hadn't thought that suggestion through.) My reason for filing this bug report was to point out that the program compilation behaves differently with and without optimization enabled. As a general rule, I think it is better that GCC's behavior does not change between varying levels of optimization. For example, let's say that when GCC chooses to inline this C99 defined "inline" function, that it also emits an external reference to the named routine. Then at link time, if no external definition is found, the link would fail, in a manner similar to the way that it does at -O0. IMO, that would be a better situation than now, because the tool chain's behavior is consistent across optimization levels. Of course, in both cases, it would be better if a more helpful error message is supplied. Based on the discussion of the C99 definition of "inline", cited by Johannes Schaub, the compiler is free to choose whether to use the inline definition or to generate an external reference. Thus, if we focus only on the translation unit, it seems that GCC could choose to compile the "inline" function as if it had been declared "static" when compiling in C99 mode with inlining disabled. This is no worse, it would seem, than inlining the function at higher levels of optimization, and not checking that an external definition for the function is defined somewhere in the linked program.
