[Bug middle-end/96771] New: arm/pr32920-2.c fails since svn r228175 / f11a7b6d57f6fcba1bf2e5a0403dc49120195320

[clyon at gcc dot gnu.org]

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

            Bug ID: 96771
           Summary: arm/pr32920-2.c fails since svn r228175 /
                    f11a7b6d57f6fcba1bf2e5a0403dc49120195320
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

The gcc.target/arm/pr43920-c testcase fails since svn r228175 / git
f11a7b6d57f6fcba1bf2e5a0403dc49120195320 (r6-3529).

That commit from 2015 says:
    revert to assign_parms assignments using default defs

    Revert the fragile and complicated changes to assign_parms designed to
    enable it to use RTL assigments chosen by cfgexpand, and instead have
    cfgexpand use the RTL assignments by assign_parms, keying them off of
    the default defs that are now necessarily introduced for each parm and
    result.  The possible lack of a default def was already a problem, and
    the fallbacks in place were not enough, as shown by PR67312.  We now
    have checking asserts in set_rtl that verify that we're assigning to
    each var a piece of RTL that matches the expectations set forth by
    use_register_for_decl.


Looking at the generated code, before the patch we had: (-mcpu=cortex-m3):
getFileStartAndLength:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        push    {r3, r4, r5, r6, r7, lr}
        mov     r6, r1
        mov     r5, r2
        movs    r1, #0
        movs    r2, #1
        mov     r7, r0
        bl      lseek
        mov     r4, r0
        movs    r2, #2
        movs    r1, #0
        mov     r0, r7
        bl      lseek
        adds    r2, r4, #1
        beq     .L4
        adds    r3, r0, #1
        beq     .L2
        subs    r0, r0, r4
        beq     .L4
        str     r4, [r6]
        str     r0, [r5]
        movs    r0, #0
        pop     {r3, r4, r5, r6, r7, pc}
.L4:
        mov     r0, #-1
.L2:
        pop     {r3, r4, r5, r6, r7, pc}

and now we have:
getFileStartAndLength:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        push    {r3, r4, r5, r6, r7, lr}
        mov     r6, r1
        mov     r5, r2
        movs    r1, #0
        movs    r2, #1
        mov     r7, r0
        bl      lseek
        mov     r4, r0
        movs    r2, #2
        movs    r1, #0
        mov     r0, r7
        bl      lseek
        adds    r2, r4, #1
        beq     .L1
        adds    r3, r0, #1
        beq     .L4
        subs    r0, r0, r4
        beq     .L4
        str     r4, [r6]
        str     r0, [r5]
        movs    r4, #0
        b       .L1
.L4:
        mov     r4, #-1
.L1:
        mov     r0, r4
        pop     {r3, r4, r5, r6, r7, pc}


The testcase fails because we now generate only one 'pop' instruction while we
expect two.

But the exit code sequence is actually longer now.
Before that patch we had either:
        pop     {r3, r4, r5, r6, r7, pc}
or
        mov     r0, #-1
        pop     {r3, r4, r5, r6, r7, pc}

We now have either:
        mov     r0, r4
        pop     {r3, r4, r5, r6, r7, pc}
or
        mov     r4, #-1
        mov     r0, r4
        pop     {r3, r4, r5, r6, r7, pc}