[Bug c/106609] New: [SH] miscompilation of loop involving noreturn call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609
Bug ID: 106609
Summary: [SH] miscompilation of loop involving noreturn call
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastien.michell...@ens-lyon.fr
Target Milestone: ---
Created attachment 53452
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53452&action=edit
Minimal test case
GCC 12.1.0 generates incorrect code for loops that call into noreturn functions
starting at -O1. For example,
__attribute__((noreturn)) void g(void);
void f(int *values)
{
for(int i = 0; i < 8; i++)
if(values[i] != 0) g();
}
gets compiled into
sts.l pr,@-r15
mov #8,r1
.L3:bt.s.L2
dt r1
mov.l .L5,r1 # _g
jsr @r1
nop
.L2:bf .L3
lds.l @r15+,pr
rts
nop
which has the obvious issue of not reading its input, and also using the T bit
through bt.s before doing any test.
I suppose this is an overly aggressive loop/CFG optimization, but I was not
able to trim it down as unfolding -O1 into the list of optimizations provided
by -Q --help=optimizers produced a completely different program. The bug still
occurs with -fno-aggressive-loop-optimizations at least.
With -funroll-all-loops, instead of 8 mov.l/tst/bf I just get 8 bf which
suggests that the test is wrongly eliminated causing the load to become dead.
Found in:
GCC 12.1.0
Commit 4991e2092 of today's master
Not found in:
GCC 11.1.0
Configured with:
../gcc-12.1.0/configure --prefix=$PREFIX --target=sh3eb-elf
--enable-languages=c --without-headers
Reproduction instructions:
$PREFIX/bin/sh3eb-elf-gcc -S noreturn-loop-bug.c -o - -O1
[Bug middle-end/106609] [SH] miscompilation of loop involving noreturn call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609 --- Comment #2 from Sébastien Michelland --- Yes there are delay slots for all branches except bt and bf, so here bt.s, jsr and rts all have one. (-fno-delayed-branches avoids them but that doesn't affect the bad optimization in this case.) Adding -fno-schedule-insns -fno-schedule-insns2 doesn't help; the test and load are still eliminated. In fact, I negated the entirety of -Q --help=optimizers and still got an incorrect output. It seems that the problem lies further downstream. I dumped various RTL stages and -fdump-rtl-mach is the first stage where the comparison to 0 is gone, if the order in the manual is anything to go by. Since I have both functional and non-functional outputs from different RTL stages, I'm switching the component to rtl-optimization.
[Bug target/106609] [SH] miscompilation due to incorrect elimination of comparisons to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609
Sébastien Michelland changed:
What|Removed |Added
Summary|[SH] miscompilation of loop |[SH] miscompilation due to
|involving noreturn call |incorrect elimination of
||comparisons to 0
--- Comment #4 from Sébastien Michelland ---
> Then this is a target specific issue until provided otherwise. mach stands
> for machine (target) specific pass.
That makes a lot of sense, thanks.
I found a much simpler example exhibiting the bug:
int f(int i, int j)
{
if(i < 0) return 1;
if(i + j) return 3;
return i;
}
Latest HEAD with -O1 (same setup as before) compiles it to
_f: cmp/pz r4
bf .L3
bf .L4
rts
mov r4,r0
.L3:rts
mov #1,r0
.L4:rts
mov #3,r0
incorrectly eliminating the test for (i + j) != 0. The label .L4 returning 3 is
evidently unreachable.
Comparing to 0 seems to be required. My previous example also compiles
correctly if we check values[i] != 1 instead, which invalidates the loop/CFG
theory.
Few commits changed the SH subtree since GCC 11.1.0; I should be able to bisect
it. In the meantime I've updated the title.
[Bug target/106609] [SH] miscompilation due to incorrect elimination of comparisons to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609
--- Comment #5 from Sébastien Michelland ---
> Then this is a target specific issue until provided otherwise. mach stands
> for machine (target) specific pass.
That makes a lot of sense, thanks.
I found a much simpler example exhibiting the bug:
int f(int i, int j)
{
if(i < 0) return 1;
if(i + j) return 3;
return i;
}
Latest HEAD with -O1 (same setup as before) compiles it to
_f: cmp/pz r4
bf .L3
bf .L4
rts
mov r4,r0
.L3:rts
mov #1,r0
.L4:rts
mov #3,r0
incorrectly eliminating the test for (i + j) != 0. The label .L4 returning 3 is
evidently unreachable.
Comparing to 0 seems to be required. My previous example also compiles
correctly if we check values[i] != 1 instead, which invalidates the loop/CFG
theory.
Few commits changed the SH subtree since GCC 11.1.0; I should be able to bisect
it. In the meantime I've updated the title.
[Bug target/106609] [SH] miscompilation due to incorrect elimination of comparisons to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609 --- Comment #6 from Sébastien Michelland --- First bad commit is r12-1955-ga86b3453fc6e29cf0e19916b01c393652d838d56, though I don't know what path is taken from there to the incorrect rewrite.
[Bug target/106609] [12 Regression] sh3eb-elf cross compiler is being miscompiled since r12-1525-g3155d51bfd1de8b6c4645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609 --- Comment #15 from Sébastien Michelland --- Thanks, turns out my bisected commit was related after all... I can confirm that test cases from OP and #4 (with protocol from OP) are no longer broken for me on yesterday's master.
