[Bug c/107931] New: [12 Regression] -Od causes always_inline to fail

[Bug c/107931] New: [12 Regression] -Od causes always_inline to fail

[me at xenu dot pl]

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

            Bug ID: 107931
           Summary: [12 Regression] -Od causes always_inline to fail
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: me at xenu dot pl
  Target Milestone: ---

The error below occurs only with -Od. The code is accepted if one of
-O0, -O1, -O2, -O3 or -Os is used instead.

This happens with GCC 12.1 and 12.2, it doesn't with 11.3.

$ cat code.c
typedef int (*fptr_t) (void);

static inline int __attribute__((always_inline)) fun4(void);

static inline void
__attribute__((always_inline))
fun3(fptr_t p)
{
    p();
}

static void
fun2(void)
{
    fun3(fun4);
}

void
fun1(void)
{
    fun2();
}

static inline int
__attribute__((always_inline))
fun4(void)
{
    return 1;
}

$ /opt/gcc-12.2.0/bin/gcc -c -Og code.c
In function ‘fun3’,
    inlined from ‘fun2’ at code.c:15:5:
code.c:26:1: error: inlining failed in call to ‘always_inline’ ‘fun4’: function
not considered for inlining
   26 | fun4(void)
      | ^~~~
code.c:9:5: note: called from here
    9 |     p();
      |     ^~~

[Bug c/107931] [12 Regression] -Og causes always_inline to fail

[me at xenu dot pl]

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

--- Comment #1 from Tomasz Konojacki <me at xenu dot pl> ---
(In reply to Tomasz Konojacki from comment #0)
> The error below occurs only with -Od.

Sorry, -Og.

PS. It seems that moving the definition of fun4 to the first line
makes the error disappear.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12 Regression] -Og causes  |[12/13 Regression] -Og
                   |always_inline to fail       |causes always_inline to
                   |                            |fail since
                   |                            |r12-6677-gc952126870c92cf2
             Status|UNCONFIRMED                 |NEW
                 CC|                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-11-30

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r12-6677-gc952126870c92cf2.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
   Target Milestone|---                         |12.3
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
always-inline and indirect function calls do not mix well, whether they are
inlined or not depends on what optimization is performed.

The re-ordering fixes things because the topological ordering of functions
for the early inlining "breaks" for indirect call edges (I wonder if we can
try to conservatively assume address-takens as calls here?)

It's considered a user error when at IPA time not all always-inline functions
are inlined.

The regression happens because we do not special-case always_inline.  With -O0
fun4 isn't inlined either but we do not diagnose that since the call
doesn't end up direct and we sofar refrain from not outputting the body
of fun4, making this a link error at -O0.

fun2:
.LFB1:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        subq    $16, %rsp
        movq    $fun4, -8(%rbp)
        movq    -8(%rbp), %rax
        call    *%rax

IMHO there's nothing to fix here.  Don't use always-inline if you have
indirect calls.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yeah, I think this is just a user error.  Define always_inline functions before
their uses if you want them inlined.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[me at xenu dot pl]

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

--- Comment #5 from Tomasz Konojacki <me at xenu dot pl> ---
To sum this thread up, there are undocumented rules that can cause a
semantically identical program to be rejected by the compiler under certain
optimisation levels (with an uninformative error message) and users are
expected to know them.

Thank you.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If you use always_inline attribute and therefore want an error if some function
isn't inlined, to be precise.  Otherwise it just wouldn't be inlined...

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 1 Dec 2022, me at xenu dot pl wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
> 
> --- Comment #5 from Tomasz Konojacki <me at xenu dot pl> ---
> To sum this thread up, there are undocumented rules that can cause a
> semantically identical program to be rejected by the compiler under certain
> optimisation levels (with an uninformative error message) and users are
> expected to know them.
> 
> Thank you.

It's even documented (I've marked the relevant sentence with
---> ... <---):

@item always_inline
@cindex @code{always_inline} function attribute
Generally, functions are not inlined unless optimization is specified.
For functions declared inline, this attribute inlines the function
independent of any restrictions that otherwise apply to inlining.
Failure to inline such a function is diagnosed as an error.
---> Note that if such a function is called indirectly the compiler may
or may not inline it depending on optimization level and a failure
to inline an indirect call may or may not be diagnosed. <---

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Just to recap here, we inline fun3 via inline_always_inline_functions and
then early_inline_small_functions bails on the call because foo4
doesn't yet have a function summary:

      /* We can encounter not-yet-analyzed function during
         early inlining on callgraphs with strongly
         connected components.  */
      ipa_fn_summary *s = ipa_fn_summaries->get (callee);
      if (s == NULL || !s->inlinable || !e->inline_failed)
        continue;

that's where the ordering constraint comes in.  That's also a hard error
in can_inline_edge_p which does

  else if (ipa_fn_summaries->get (callee) == NULL
           || !ipa_fn_summaries->get (callee)->inlinable)
    { 
      e->inline_failed = CIF_FUNCTION_NOT_INLINABLE;
      inlinable = false;

even if we'd try harder and re-do inline_always_inline_functions after
each inline step (up to max early inliner iterations).  Maybe for QOI
we can handle this special case in ipa_reverse_postorder by putting
address-taken nodes without any calls last (we don't seem to have
indirect edges at this point to do a better job):

diff --git a/gcc/ipa-utils.cc b/gcc/ipa-utils.cc
index 67dd42f4faf..75e1387714e 100644
--- a/gcc/ipa-utils.cc
+++ b/gcc/ipa-utils.cc
@@ -294,7 +294,7 @@ ipa_reverse_postorder (struct cgraph_node **order)
   for (pass = 0; pass < 2; pass++)
     FOR_EACH_FUNCTION (node)
       if (!node->aux
-         && (pass
+         && ((pass && !(!node->callees && node->address_taken))
              || (!node->address_taken
                  && !node->inlined_to
                  && !node->alias && !node->thunk
@@ -346,7 +346,10 @@ ipa_reverse_postorder (struct cgraph_node **order)
        }
   free (stack);
   FOR_EACH_FUNCTION (node)
-    node->aux = NULL;
+    if (!node->aux)
+      order[order_pos++] = node;
+    else
+      node->aux = NULL;
   return order_pos;
 }

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[sam at gentoo dot org]

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

--- Comment #9 from Sam James <sam at gentoo dot org> ---
For completeness, this originated from
https://github.com/Perl/perl5/issues/19776, I believe.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[ishikawa at yk dot rim.or.jp]

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

ishikawa,chiaki <ishikawa at yk dot rim.or.jp> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ishikawa at yk dot rim.or.jp

--- Comment #10 from ishikawa,chiaki <ishikawa at yk dot rim.or.jp> ---
Created attachment 54483
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54483&action=edit
The source file that exhibits the failure to inline always_inline functions.

I have a similar problem compiling Thunderbird mail client with GCC-12.
A couple of always_inline functions cannot be inlined and errors are diagnosed.

I am a bit perplexed that gcc-10 and gcc-11 did not seem to have the problem.
Also, I am wondering if I am seeing the same issue discussed here or not
because I think the functions are declared in the proper topological order
(that is, the function that is called is declared in a manner that the callee
is defined before the caller.)
Yes, there is an indirect function call, that may be the reason of the failure.

I am attaching a preprocessed source file and the script to compile it to cause
the failure. 
The presence of -Og is essential. If we remove -Og, the compilation succeeds.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[ishikawa at yk dot rim.or.jp]

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

--- Comment #11 from ishikawa,chiaki <ishikawa at yk dot rim.or.jp> ---
Created attachment 54484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54484&action=edit
Script to compile the previous source file.

The previous source file ought to be named
't-failure-always-inline-simplified.c'.
This script compiles it.
With -Og the compilation fails since always_inline functions do not get
inlined.
Without -Og, the compilation succeeds.

Of course, we can conditionalize the use of always_inline to avoid the issue.
What is exactly the compiler-defined macro when "-Og" is used on the command
line?

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=61782

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #7)
> It's even documented (I've marked the relevant sentence with
> ---> ... <---):
> 
> @item always_inline
> @cindex @code{always_inline} function attribute
> Generally, functions are not inlined unless optimization is specified.
> For functions declared inline, this attribute inlines the function
> independent of any restrictions that otherwise apply to inlining.
> Failure to inline such a function is diagnosed as an error.
> ---> Note that if such a function is called indirectly the compiler may
> or may not inline it depending on optimization level and a failure
> to inline an indirect call may or may not be diagnosed. <---

And been documented that way since 2014 even (r5-1859-g3defdb14996a82 aka PR
61782)

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[pinskia at gcc dot gnu.org]

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

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to ishikawa,chiaki from comment #11)
> What is exactly the compiler-defined macro when "-Og" is used on the command
> line?

There is not one ...

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[ishikawa at yk dot rim.or.jp]

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

--- Comment #14 from ishikawa,chiaki <ishikawa at yk dot rim.or.jp> ---
(In reply to Andrew Pinski from comment #13)
> (In reply to ishikawa,chiaki from comment #11)
> > What is exactly the compiler-defined macro when "-Og" is used on the command
> > line?
> 
> There is not one ...

Thank you for the information.
I see we may have to create a protocol by creating a commonly used macro to
handle the situation.

The bugzilla I created at mozilla is
https://bugzilla.mozilla.org/show_bug.cgi?id=1817565

And the code seems to be a third party code and I was advised to report the
issue to the originating github also.
I will.

Thank you again.

PS: Given the manual description, it could be gcc-10 and gcc-11 may not have
inlined the functions, but the errors were not reported as such. Oh well.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to ishikawa,chiaki from comment #14)
> (In reply to Andrew Pinski from comment #13)
> > (In reply to ishikawa,chiaki from comment #11)
> > > What is exactly the compiler-defined macro when "-Og" is used on the command
> > > line?
> > 
> > There is not one ...
> 
> Thank you for the information.
> I see we may have to create a protocol by creating a commonly used macro to
> handle the situation.
> 
> The bugzilla I created at mozilla is
> https://bugzilla.mozilla.org/show_bug.cgi?id=1817565
> 
> And the code seems to be a third party code and I was advised to report the
> issue to the originating github also.
> I will.
> 
> Thank you again.
> 
> PS: Given the manual description, it could be gcc-10 and gcc-11 may not have
> inlined the functions, but the errors were not reported as such. Oh well.

It is generally not possible to compute all indirect call sites to an
always_inline function.  It would be possible to simply disallow taking
the address of an always_inline function but we rejected that based on
the use of indirect calls to always_inline functions in the wild but instead
opted to document that we do not really support this usage.  A weaker
option to never emit the body of an always_inline function out-of-line
was rejected as well (you'd then a least get linker errors for missed
[indirect] calls).

We could opt to _not_ diagnose such missed inlines iff the function had
its address taken at some point, but then you won't notice missed inlines
of always-inline either.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As discussed elsewhere, always_inline is used in various ways, in some users I
guess would like to see an error if it wasn't inlined, but e.g. the uses in
glibc for _FORTIFY_SOURCE where many of the standard C or POSIX APIs have
extern inline wrappers with always_inline and gnu_inline attributes.  In that
case always_inline is used there for security reasons (not inlining it means
the security checks aren't done) but on the other side C/POSIX requires &open
or &printf to work too.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[rguenther at suse dot de]

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

--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 20 Feb 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
> 
> --- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> As discussed elsewhere, always_inline is used in various ways, in some users I
> guess would like to see an error if it wasn't inlined, but e.g. the uses in
> glibc for _FORTIFY_SOURCE where many of the standard C or POSIX APIs have
> extern inline wrappers with always_inline and gnu_inline attributes.  In that
> case always_inline is used there for security reasons (not inlining it means
> the security checks aren't done) but on the other side C/POSIX requires &open
> or &printf to work too.

With GNU extern inline always_inline it would work to never emit bodies
of always_inline functions to get the errors diagnosed at link time.
Possibly standard C inline plus always_inline would work the same if we
then treat the out of line instantiation as the destination for indirect
calls.

But I think the cgraph code is still not 100% accurate in reflecting
reality with extern inlines (and possibly C 'inline' and instantiations),
since it doesn't treat the inline copy and the out of line copy 
separately.

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[ishikawa at yk dot rim.or.jp]

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

--- Comment #18 from ishikawa,chiaki <ishikawa at yk dot rim.or.jp> ---
I reported the issue to the following github for a very fast hashing function
library.
https://github.com/Cyan4973/xxHash/issues/800

From the discussion there, I figured -Og does not define __NO_INLINE__ as -O0
would define it.
Well the discussion refers to the problem mentioned earlier about the same
issue.
In there, the following mentions something about __NO_INLINE__.
https://github.com/Cyan4973/xxHash/pull/720#issuecomment-1414481935


So I settled on manually define __NO_INLINE__ on the compiler command line.
This makes it the compilation succeed.
(The code seems to be written in such a manner that always_inline is not 
declared for the two functions if __NO_INLINE__ is defiend.)

It would be great if -Og can define macro __NO_INLINE__ as -O0 does.
Oh wait, -fno-inline has the same effect(?).

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[rguenther at suse dot de]

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

--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 21 Feb 2023, ishikawa at yk dot rim.or.jp wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
> 
> --- Comment #18 from ishikawa,chiaki <ishikawa at yk dot rim.or.jp> ---
> I reported the issue to the following github for a very fast hashing function
> library.
> https://github.com/Cyan4973/xxHash/issues/800
> 
> From the discussion there, I figured -Og does not define __NO_INLINE__ as -O0
> would define it.
> Well the discussion refers to the problem mentioned earlier about the same
> issue.
> In there, the following mentions something about __NO_INLINE__.
> https://github.com/Cyan4973/xxHash/pull/720#issuecomment-1414481935
> 
> 
> So I settled on manually define __NO_INLINE__ on the compiler command line.
> This makes it the compilation succeed.
> (The code seems to be written in such a manner that always_inline is not 
> declared for the two functions if __NO_INLINE__ is defiend.)
> 
> It would be great if -Og can define macro __NO_INLINE__ as -O0 does.
> Oh wait, -fno-inline has the same effect(?).

-Og does inline small functions so defining __NO_INLINE__ would not
be correct

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[hubicka at ucw dot cz]

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

--- Comment #20 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
> 
> --- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> ---
> On Mon, 20 Feb 2023, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
> > 
> > --- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> > As discussed elsewhere, always_inline is used in various ways, in some users I
> > guess would like to see an error if it wasn't inlined, but e.g. the uses in
> > glibc for _FORTIFY_SOURCE where many of the standard C or POSIX APIs have
> > extern inline wrappers with always_inline and gnu_inline attributes.  In that
> > case always_inline is used there for security reasons (not inlining it means
> > the security checks aren't done) but on the other side C/POSIX requires &open
> > or &printf to work too.
> 
> With GNU extern inline always_inline it would work to never emit bodies
> of always_inline functions to get the errors diagnosed at link time.
> Possibly standard C inline plus always_inline would work the same if we
> then treat the out of line instantiation as the destination for indirect
> calls.
> 
> But I think the cgraph code is still not 100% accurate in reflecting
> reality with extern inlines (and possibly C 'inline' and instantiations),
> since it doesn't treat the inline copy and the out of line copy 
> separately.
Yep, when inline version is replaced by offline version we forget inline
version. THis is remainer from one-definition rule work Zack did many years
ago. He changed C and C++ frontned to not produce duplciated
VAR/FUNCTION_DECLs with same assembler names and do in-place
replacements instead.  This was never fully finished and we get
duplciates in some scnearios.

In meantime cgraph knows how to handle this for LTO and we also support
weakrefs and syntactic aliases so keeping both definitions around is not
too hard from cgraph point of view.  We will however need to convince
front-ends to not overwrite the original decl holding the extern inline
body.

Honza

[Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.3                        |12.4

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 12.3 is being released, retargeting bugs to GCC 12.4.

[Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
The report as-is is invalid.  The issue with always_inline not being exactly
the right tool and missing alternatives is tracked in various duplicates.

I'm closing this one given the real issue isn't a regression.

[Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Couldn't we conditionalize that
      if (!opt_for_fn (node->decl, optimize)
         /* With -Og we do not want to perform IPA inlining of small
            functions since there are no scalar cleanups after it
            that would realize the anticipated win.  All abstraction
            is removed during early inlining.  */
         || opt_for_fn (node->decl, optimize_debug))
        continue;
on the callee not being always_inline?

[Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[rguenth at gcc dot gnu.org]

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

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #23)
> Couldn't we conditionalize that
>       if (!opt_for_fn (node->decl, optimize)
>          /* With -Og we do not want to perform IPA inlining of small
>             functions since there are no scalar cleanups after it
>             that would realize the anticipated win.  All abstraction
>             is removed during early inlining.  */
>          || opt_for_fn (node->decl, optimize_debug))
>         continue;
> on the callee not being always_inline?

You mean on there being no always_inline callee?  This iterates over
the functions we inline _into_.  We don't really special-case always-inline
during IPA since we expect all of them inlined early.

But yes, that would probably mean skipping non-always-inline edges
during enqueueing calls.

[Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[rguenth at gcc dot gnu.org]

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

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, I'd rather go the opposite and make the testcase at hand always invalid
and diagnosed which means diagnose taking the address of always-inline declared
functions and never emit an out-of-line body for them.

[Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #25)
> Btw, I'd rather go the opposite and make the testcase at hand always invalid
> and diagnosed which means diagnose taking the address of always-inline
> declared functions and never emit an out-of-line body for them.

That would need an exception at least for gnu extern inline always_inline
functions,
because the way they are used in glibc requires &open etc. to be valid (and use
then as fallback the out of line open).
But with the exception we can still see those indirect uses optimized later
into direct calls.

[Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[rguenther at suse dot de]

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

--- Comment #27 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 23 Jan 2024, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
> 
> --- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #25)
> > Btw, I'd rather go the opposite and make the testcase at hand always invalid
> > and diagnosed which means diagnose taking the address of always-inline
> > declared functions and never emit an out-of-line body for them.
> 
> That would need an exception at least for gnu extern inline always_inline
> functions,
> because the way they are used in glibc requires &open etc. to be valid (and use
> then as fallback the out of line open).

Sure, already the C frontend should resolve to the out-of-line open call
there, we shouldn't do this in the middle-end.  Yes, indirect 'open' will
then not be fortified, but so what.