https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86360
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> --- (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". Agreed.
