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.
