[Bug target/94531] New: gcc.target/arm/its.c fails for cortex-m3
clyon at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Wed Apr 8 14:53:36 GMT 2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94531
Bug ID: 94531
Summary: gcc.target/arm/its.c fails for cortex-m3
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
I've noticed that gcc.target/arm/its.c fails when targetting
cortex-m3 or m33, but that's probably true with all cortex-m versions.
The code generated at r206697 (just before the test was
introduced) was (max cond insns = 5):
test:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmp r0, #10
itete gt
subgt r0, r0, r1
suble r0, r1, r0
addgt r0, r0, #10
suble r0, r0, #7
cmp r0, #0
it gt
subgt r0, r0, #3
bx lr
At r206698 (arm.c (arm_v7m_tune): Set max_insns_skipped to 2),
which introduced its.c, the generated code is the same as above,
so it seems that r206698 was wrong and the problem was not caught
by the testcase.
The testcase started to fail at r249215 (Make
gcc.target/arm/its.c more robust), but the generated code was
still the same.
As of recent trunk. the generated code is:
test:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmp r0, #10
itete gt
subgt r1, r0, r1
suble r1, r1, r0
addgt r0, r1, #10
suble r0, r1, #7
cmp r0, #0
it gt
subgt r0, r0, #3
bx lr
That is, almost same, except that r1 is used as temporary instead
of r0 in some parts.
Reducing max cond insns to 1 produces:
test:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmp r0, #10
ble .L2
subs r1, r0, r1
add r0, r1, #10
cmp r0, #0
it gt
subgt r0, r0, #3
bx lr
.L2:
subs r1, r1, r0
subs r0, r1, #7
cmp r0, #0
it gt
subgt r0, r0, #3
bx lr
Increasing max cond insns back to 5 produces the same code as with '2'.
Since there was little justification of the patches around this
test, I'm wondering whether the current is bad or should we just
change the test?
More information about the Gcc-bugs
mailing list