[forwarded from https://bugs.debian.org/853613] seen with the gcc-7-branch $ cat test4.c int a; inline void builddircommand(void) { a++; } void test(void) { builddircommand(); } int main() {return 0;} $ gcc-6 -O2 -Wall test4.c $ gcc-6 -Os -Wall test4.c $ gcc-7 -O2 -Wall test4.c $ gcc-7 -Os -Wall test4.c /tmp/ccRQcwvp.o: In function `test': test4.c:(.text+0x1): undefined reference to `builddircommand' collect2: error: ld returned 1 exit status
Hmm. I don't remember the c11 semantics when it comes to plain inline. This might not be a bug ...
but shouldn't these the same with different optimization levels?
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.