> When an inline function is not static, then the compiler must assume
> that there may be calls from other source files; since a global symbol
> can be defined only once in any program, the function must not be defined
> in the other source files, so the calls therein cannot be integrated.
> Therefore, a non-static inline function is always compiled on its own
> in the usual fashion.
Either I misunderstand that, or it isn't true:
$ cat foo.c
inline int foo(int a)
int main(int a)
$ gcc -O0 -o- -S foo.c
.type bar, @function
.cfi_offset 6, -16
movq %rsp, %rbp
subq $16, %rsp
movl %edi, -4(%rbp)
movl -4(%rbp), %eax
movl %eax, %edi
.cfi_def_cfa 7, 8
.size bar, .-bar
.ident "GCC: (GNU) 8.1.1 20180502 (Red Hat 8.1.1-1)"
Note the 'foo' function doesn't get emitted.
"The remainder of this section is specific to GNU C90 inlining." and you're compiling with the defaultoptions, which means -std=gnu99 so you get C99 inlining.
Use -std=gnu90 to get GNU 90 semantics, and a definition emitted.
See "Different semantics for inline functions" at https://gcc.gnu.org/gcc-5/porting_to.html for more details.
Thanks for the prompt response.
I'll stick with my original "compiler isn't required to emit" comment in my referenced patch submission, which everyone had questioned...
More than that, I don't think it's allowed to. See 6.7.4 p7 in the C11 standard.
"An inline definition does not provide an external definition for the function,
and does not forbid an external definition in another translation unit."
Well, it's *allowed* to emit it inline. But if it doesn't then it mustn't emit it out-of-line. At least, from your citation, it mustn't emit it out-of-line such that it can be seen from another translation unit.
I'm not sure if it would be permitted for a compiler to emit that function as a static (but out-of-line) function. Perhaps if there's no extern definition of the same function, that might be a reasonable thing for a compiler to do?
But frankly I don't care much either. I already submitted a patch to make the code that offended me use 'static inline', and although I allowed myself to be talked into filing this PR I'm more than happy just to point at the response and say "no, my initial analysis was correct".
(In reply to David Woodhouse from comment #5)
> Well, it's *allowed* to emit it inline. But if it doesn't then it mustn't
> emit it out-of-line. At least, from your citation, it mustn't emit it
> out-of-line such that it can be seen from another translation unit.
> I'm not sure if it would be permitted for a compiler to emit that function
> as a static (but out-of-line) function.
It's allowed to, yes. It could produce a definition with internal linkage and make the call go to that, which would not depend on an external definition existing elsewhere.
"An inline definition provides an alternative to an external definition, which a translator may use to implement any call to the function in the same translation unit. It is unspecified whether a call to the function uses the inline definition or the external definition."
Using the inline definition doesn't actually require any code to be inlined into the caller, it could just emit a definition with internal linkage and emit a call to that instead.
> Perhaps if there's no extern
> definition of the same function, that might be a reasonable thing for a
> compiler to do?
Yes. It would avoid a linker error if there is no corresponding extern definition elsewhere in the program.
I think in practice what GCC does is either inline the code into the caller (but only when optimization is enabled) or emit a call to an extern function (which then needs to exist).
> But frankly I don't care much either. I already submitted a patch to make
> the code that offended me use 'static inline', and although I allowed myself
> to be talked into filing this PR I'm more than happy just to point at the
> response and say "no, my initial analysis was correct".