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}