* [Bug c/107931] [12 Regression] -Og causes always_inline to fail
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
@ 2022-11-30 7:55 ` me at xenu dot pl
2022-11-30 12:30 ` [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2 marxin at gcc dot gnu.org
` (26 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: me at xenu dot pl @ 2022-11-30 7:55 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
2022-11-30 7:55 ` [Bug c/107931] [12 Regression] -Og " me at xenu dot pl
@ 2022-11-30 12:30 ` marxin at gcc dot gnu.org
2022-11-30 12:52 ` rguenth at gcc dot gnu.org
` (25 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-11-30 12:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
2022-11-30 7:55 ` [Bug c/107931] [12 Regression] -Og " me at xenu dot pl
2022-11-30 12:30 ` [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2 marxin at gcc dot gnu.org
@ 2022-11-30 12:52 ` rguenth at gcc dot gnu.org
2022-12-01 15:34 ` jakub at gcc dot gnu.org
` (24 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-11-30 12:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (2 preceding siblings ...)
2022-11-30 12:52 ` rguenth at gcc dot gnu.org
@ 2022-12-01 15:34 ` jakub at gcc dot gnu.org
2022-12-01 17:59 ` me at xenu dot pl
` (23 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-01 15:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (3 preceding siblings ...)
2022-12-01 15:34 ` jakub at gcc dot gnu.org
@ 2022-12-01 17:59 ` me at xenu dot pl
2022-12-01 18:02 ` jakub at gcc dot gnu.org
` (22 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: me at xenu dot pl @ 2022-12-01 17:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (4 preceding siblings ...)
2022-12-01 17:59 ` me at xenu dot pl
@ 2022-12-01 18:02 ` jakub at gcc dot gnu.org
2022-12-02 7:22 ` rguenther at suse dot de
` (21 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-01 18:02 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (5 preceding siblings ...)
2022-12-01 18:02 ` jakub at gcc dot gnu.org
@ 2022-12-02 7:22 ` rguenther at suse dot de
2022-12-21 10:44 ` rguenth at gcc dot gnu.org
` (20 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenther at suse dot de @ 2022-12-02 7:22 UTC (permalink / raw)
To: gcc-bugs
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. <---
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (6 preceding siblings ...)
2022-12-02 7:22 ` rguenther at suse dot de
@ 2022-12-21 10:44 ` rguenth at gcc dot gnu.org
2023-02-17 10:16 ` sam at gentoo dot org
` (19 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-12-21 10:44 UTC (permalink / raw)
To: gcc-bugs
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;
}
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (7 preceding siblings ...)
2022-12-21 10:44 ` rguenth at gcc dot gnu.org
@ 2023-02-17 10:16 ` sam at gentoo dot org
2023-02-18 6:32 ` ishikawa at yk dot rim.or.jp
` (18 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: sam at gentoo dot org @ 2023-02-17 10:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (8 preceding siblings ...)
2023-02-17 10:16 ` sam at gentoo dot org
@ 2023-02-18 6:32 ` ishikawa at yk dot rim.or.jp
2023-02-18 6:35 ` ishikawa at yk dot rim.or.jp
` (17 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ishikawa at yk dot rim.or.jp @ 2023-02-18 6:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (9 preceding siblings ...)
2023-02-18 6:32 ` ishikawa at yk dot rim.or.jp
@ 2023-02-18 6:35 ` ishikawa at yk dot rim.or.jp
2023-02-18 7:05 ` pinskia at gcc dot gnu.org
` (16 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ishikawa at yk dot rim.or.jp @ 2023-02-18 6:35 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (10 preceding siblings ...)
2023-02-18 6:35 ` ishikawa at yk dot rim.or.jp
@ 2023-02-18 7:05 ` pinskia at gcc dot gnu.org
2023-02-18 7:10 ` pinskia at gcc dot gnu.org
` (15 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-02-18 7:05 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (11 preceding siblings ...)
2023-02-18 7:05 ` pinskia at gcc dot gnu.org
@ 2023-02-18 7:10 ` pinskia at gcc dot gnu.org
2023-02-18 23:34 ` ishikawa at yk dot rim.or.jp
` (14 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-02-18 7:10 UTC (permalink / raw)
To: gcc-bugs
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 ...
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (12 preceding siblings ...)
2023-02-18 7:10 ` pinskia at gcc dot gnu.org
@ 2023-02-18 23:34 ` ishikawa at yk dot rim.or.jp
2023-02-20 7:49 ` rguenth at gcc dot gnu.org
` (13 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ishikawa at yk dot rim.or.jp @ 2023-02-18 23:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (13 preceding siblings ...)
2023-02-18 23:34 ` ishikawa at yk dot rim.or.jp
@ 2023-02-20 7:49 ` rguenth at gcc dot gnu.org
2023-02-20 10:40 ` jakub at gcc dot gnu.org
` (12 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-02-20 7:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (14 preceding siblings ...)
2023-02-20 7:49 ` rguenth at gcc dot gnu.org
@ 2023-02-20 10:40 ` jakub at gcc dot gnu.org
2023-02-20 10:51 ` rguenther at suse dot de
` (11 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-20 10:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (15 preceding siblings ...)
2023-02-20 10:40 ` jakub at gcc dot gnu.org
@ 2023-02-20 10:51 ` rguenther at suse dot de
2023-02-21 7:33 ` ishikawa at yk dot rim.or.jp
` (10 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenther at suse dot de @ 2023-02-20 10:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (16 preceding siblings ...)
2023-02-20 10:51 ` rguenther at suse dot de
@ 2023-02-21 7:33 ` ishikawa at yk dot rim.or.jp
2023-02-21 7:36 ` rguenther at suse dot de
` (9 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ishikawa at yk dot rim.or.jp @ 2023-02-21 7:33 UTC (permalink / raw)
To: gcc-bugs
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(?).
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (17 preceding siblings ...)
2023-02-21 7:33 ` ishikawa at yk dot rim.or.jp
@ 2023-02-21 7:36 ` rguenther at suse dot de
2023-02-21 11:56 ` hubicka at ucw dot cz
` (8 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenther at suse dot de @ 2023-02-21 7:36 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (18 preceding siblings ...)
2023-02-21 7:36 ` rguenther at suse dot de
@ 2023-02-21 11:56 ` hubicka at ucw dot cz
2023-05-08 12:26 ` [Bug ipa/107931] [12/13/14 " rguenth at gcc dot gnu.org
` (7 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: hubicka at ucw dot cz @ 2023-02-21 11:56 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (19 preceding siblings ...)
2023-02-21 11:56 ` hubicka at ucw dot cz
@ 2023-05-08 12:26 ` rguenth at gcc dot gnu.org
2024-01-12 10:11 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-05-08 12:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (20 preceding siblings ...)
2023-05-08 12:26 ` [Bug ipa/107931] [12/13/14 " rguenth at gcc dot gnu.org
@ 2024-01-12 10:11 ` rguenth at gcc dot gnu.org
2024-01-12 10:26 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-01-12 10:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (21 preceding siblings ...)
2024-01-12 10:11 ` rguenth at gcc dot gnu.org
@ 2024-01-12 10:26 ` jakub at gcc dot gnu.org
2024-01-12 11:56 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-01-12 10:26 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (22 preceding siblings ...)
2024-01-12 10:26 ` jakub at gcc dot gnu.org
@ 2024-01-12 11:56 ` rguenth at gcc dot gnu.org
2024-01-23 8:31 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-01-12 11:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (23 preceding siblings ...)
2024-01-12 11:56 ` rguenth at gcc dot gnu.org
@ 2024-01-23 8:31 ` rguenth at gcc dot gnu.org
2024-01-23 8:39 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-01-23 8:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (24 preceding siblings ...)
2024-01-23 8:31 ` rguenth at gcc dot gnu.org
@ 2024-01-23 8:39 ` jakub at gcc dot gnu.org
2024-01-23 10:30 ` rguenther at suse dot de
2024-07-03 4:58 ` pinskia at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-01-23 8:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (25 preceding siblings ...)
2024-01-23 8:39 ` jakub at gcc dot gnu.org
@ 2024-01-23 10:30 ` rguenther at suse dot de
2024-07-03 4:58 ` pinskia at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: rguenther at suse dot de @ 2024-01-23 10:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug ipa/107931] [12/13/14 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
2022-11-30 7:52 [Bug c/107931] New: [12 Regression] -Od causes always_inline to fail me at xenu dot pl
` (26 preceding siblings ...)
2024-01-23 10:30 ` rguenther at suse dot de
@ 2024-07-03 4:58 ` pinskia at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-07-03 4:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Changqing.Li at windriver dot com
--- Comment #28 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 115679 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 29+ messages in thread