[Bug c/113203] New: __attribute__ ((always_inline)) fails with C99/LTO/-Og.

[Bug c/113203] New: __attribute__ ((always_inline)) fails with C99/LTO/-Og.

[stefan at bytereef dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203

            Bug ID: 113203
           Summary: __attribute__ ((always_inline)) fails with
                    C99/LTO/-Og.
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: stefan at bytereef dot org
  Target Milestone: ---

This is similar to #107931. I'm opening a new issue because there are no
indirect function calls and the problem occurs with -std=c99 -flto -Og.


foo.c
========================================================
#include <stdbool.h>
#include "foo.h"

inline __attribute__ ((always_inline)) bool
f(int x)
{
  return (x > 2);
}
========================================================

foo.h
========================================================
#include <stdbool.h>
bool f(int);
========================================================

main.c
========================================================
#include <stdio.h>
#include "foo.h"

int
main(int argc, char *argv[])
{
   (void)argv;

   if (f(argc)) {
     puts("yes");
   }
   else {
     puts("no");
   }

   return 0;
}
========================================================



$ gcc -Wall -Wextra -std=c99 -flto -Og -o main foo.c main.c

foo.c: In function ‘main’:
foo.c:5:1: error: inlining failed in call to ‘always_inline’ ‘f’: function not
considered for inlining
    5 | f(int x)
      | ^
main.c:9:8: note: called from here
    9 |    if (f(argc)) {
      |        ^
lto-wrapper: fatal error: /home/skrah/gcc/bin/gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed




This is extracted from the mpdecimal project that has used C99 and
always_inline for a decade without problems. The code was written before the
amendment to the always_inline documentation in 2014 and always_inline has
consistently produced a speedup of 1-2.5% even with -O3.


My questions:

1) Since this is C99, should always_inline work without errors when -std=c99 is
active? If not, should -std=c99 reject always_inline?

2) There is a clear demand for something like "really_inline" that ignores the
heuristics and just inlines whenever possible without errors or warnings. In
practice that is how MSVC __forceinline or clang always_inline behave. Could
that be added?

[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I thought there was another bug related to using always_inline and LTO.

[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.

[stefan at bytereef dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203

--- Comment #4 from Stefan Krah <stefan at bytereef dot org> ---
> 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.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |documentation
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
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.