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?

Reply via email to