For the record: At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81734#c3 Jakub Jelinek wrote on 2017-08-07 07:37:55 UTC: >> 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.
I'm investing some time in working on this issue now. Bye, Joost
signature.asc
Description: Digital signature
