https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81734
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |jakub at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The C99/C11 inlining semantics in this case is that if it is possible and
desirable to inline the function, then it is inlined, but the out-of-line copy
of the inlined function has to be emitted in some other TU.
(In reply to Matthias Klose from comment #2)
> but shouldn't these the same with different optimization levels?
Of course not. Whether it is desirable to inline something is an optimization
decision, at -O0 we don't inline anything (unless it has always_inline
attribute), at -Os we inline if the heuristics determines that inlining will
likely make the code smaller, at -O2 etc. if it determines that inlining will
likely make the code faster.
So, for the broken pinfo package, you need to decide what you want.
Either you want it to be inlined always, no matter what, then it needs
always_inline attribute, or if it is not desirable to inline, you want a static
copy of the out of line function in every TU that needs it, then it should be
static inline, or you want out of line copy in one TU and not the others, then
you use what you have above in all but one TU, and in that last TU add extern
void builddircommand(void);, or you want the GNU inline semantics, then you add
gnu_inline attribute and again read the rules for it.
See https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Inline.html and the C standard
for more details.
