[Bug target/94531] New: gcc.target/arm/its.c fails for cortex-m3

[Bug target/94531] New: gcc.target/arm/its.c fails for cortex-m3

[clyon at gcc dot gnu.org]

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?

[Bug target/94531] gcc.target/arm/its.c fails for cortex-m3

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon <clyon at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #0)
> 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.
> 
Since I have extending testing to more CPUs, I've noticed that the test fails
for M3, M4 and M33, but passes for M7 (which has '1' as max_insns_skipped
tuning, while other v7m CPUs have '2').

If these are the expected results, that's not easy to describe in the testcase
:-)