[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203 --- Comment #8 from Stefan Krah --- As Richard wrote, C99 demands that an additional out-of-line copy of the function is generated. Whether the non-standard __attribute__ ((always_inline)) should override C99 is of course another question. For users the strictness of always_inline seems tricky. I'd welcome an additional "really_inline" that ignores the heuristics but does not fail with a compile error if inlining is not possible.
[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203 --- Comment #6 from GCC Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:fc89b1face0d207710eaa3d8f5af3adcffd5c5c9 commit r15-9475-gfc89b1face0d207710eaa3d8f5af3adcffd5c5c9 Author: Sandra Loosemore Date: Tue Apr 15 03:49:06 2025 + Doc: always_inline attribute vs multiple TUs and LTO [PR113203] gcc/ChangeLog PR ipa/113203 * doc/extend.texi (Common Function Attributes): Explain how to use always_inline in programs that have multiple translation units, and that LTO inlining additionally needs optimization enabled.
[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #7 from sandra at gcc dot gnu.org --- I'm not sure if the documentation patch I pushed is adequate to mark this as fixed, or if some actual changes in GCC behavior are needed too. I think the high-order bit is to tell users "don't try to do that", though.
[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203 Richard Biener changed: What|Removed |Added Keywords||documentation CC||hubicka at gcc dot gnu.org --- Comment #5 from Richard Biener --- With -Og we specifically disable IPA inlining, not considering that always-inline functions might only appear with LTO. I don't think that cross-TU "always-inline" is sensible, and we probably should not merge the always-inline definition with the not always-inline declaration that's effective for the call in question. So we should accept the code at compile-time but not honor always-inline cross-TU in the way it is presented by the testcase. The bool f(int); declaration should force an out-of-line copy of the C99 inline, right? And GCC always-inline doesn't change that? Btw, the same should happen with -O2 -flto but __attribute__((optimize(0))) on main(). It might be worth amending the always-inline documentation as well.
[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203
--- Comment #4 from Stefan Krah ---
> Or, if the intention is that all calls to the function within its TU
> are inlined and not the other ones, split the function into two, one
> always_inline which is used from within the TU and another one which
> just calls it and is used from other TUs.
Yes, that's the intention. The real project has more than 100 functions in
mpdecimal.c. I'm using C99 inline to both automatically inline functions
specifically in that TU but generate regular functions for the other TUs
and libmpdec.so.
C99 saves the work of creating the wrappers manually.
Do note that this issue started with gcc-12, same as in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
So it's a behavior change. I agree that the combination of "-flto -Og" is not
particularly important. But is it guaranteed that the above C99 scheme will
always work with -O{1,2,3}? Or are there other loopholes that might show up
in the future?
I guess that in order to be safe I'll remove always_inline and use your wrapper
suggestion some time in the future.
[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- If you want to make something always_inline, define it in the header rather than having just a non-always_inline declaration in the header and definition in some TU. Because without LTO that means it will never be actually attempted to be inlined, and with LTO it can't be inlined until the IPA inlining which -O0 or -Og don't perform. Or, if the intention is that all calls to the function within its TU are inlined and not the other ones, split the function into two, one always_inline which is used from within the TU and another one which just calls it and is used from other TUs.
[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203 --- Comment #2 from Andrew Pinski --- I am not 100% sure if this is a bug here since you are requesting across TU always_inline but at -Og, that is basically not enabled. Maybe not use always_inline for -O0 and -Og builds?
[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203 --- Comment #1 from Andrew Pinski --- I thought there was another bug related to using always_inline and LTO.
