Bug 109347 - Spill failure for architecture without CC
Summary: Spill failure for architecture without CC
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 12.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code, ra
Depends on:
Blocks:
 
Reported: 2023-03-30 18:59 UTC by Piggy NL
Modified: 2023-04-05 23:35 UTC (History)
1 user (show)

See Also:
Host:
Target: riscv32-elf, riscv64-elf, mips64-eabi
Build:
Known to work:
Known to fail: 4.7.0, 7.3.0
Last reconfirmed: 2023-03-30 00:00:00


Attachments
Reproduce for riscv64 (646 bytes, text/x-csrc)
2023-03-30 18:59 UTC, Piggy NL
Details
Reproduce for mips64 (599 bytes, text/x-csrc)
2023-03-30 18:59 UTC, Piggy NL
Details
Fixed up riscv64 testcase (649 bytes, text/plain)
2023-03-30 19:38 UTC, Andrew Pinski
Details
testcase for riscv32-elf (648 bytes, text/plain)
2023-03-30 19:39 UTC, Andrew Pinski
Details
testcase for riscv64-elf and riscv32-elf (686 bytes, text/plain)
2023-03-30 19:42 UTC, Andrew Pinski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Piggy NL 2023-03-30 18:59:37 UTC
Created attachment 54791 [details]
Reproduce for riscv64

For all architectures without condition code, when all registers are in use, gcc fails to perform a spill.

mips64 and riscv64 are failing with certain code. 

For example, the codes for mips64 and riscv64 reproducing the bug are in attachments.

The expected behavior is generating a spill asm sequence before the `if` block and a restore sequence after, so it will be a free register in the `if` block.

gcc is failing an assertion error with the examples. With a release build, gcc falls into an infinity loop.

The assertion fails in lra.c:

	    if (e->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
	      {
		/* We already made the edge no-critical in ira.c::ira */
		lra_assert (!EDGE_CRITICAL_P (e));
		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
		rtx_insn *tmp = BB_HEAD (e->dest);
		if (LABEL_P (tmp))

The assertion was introduced in e3b3b59683c1.
Comment 1 Piggy NL 2023-03-30 18:59:59 UTC
Created attachment 54792 [details]
Reproduce for mips64
Comment 2 Andrew Pinski 2023-03-30 19:32:24 UTC
(In reply to Piggy NL from comment #0)
> The assertion was introduced in e3b3b59683c1.

r11-5002-ge3b3b59683c1e7
Comment 3 Andrew Pinski 2023-03-30 19:36:16 UTC
On the trunk I get:
t.c: In function ‘f’:
t.c:94:1: error: s0 cannot be used in ‘asm’ here
   94 | }
      | ^

First with the RISCV example.
After removing the s0 variable usage I still get the ICE.
Comment 4 Andrew Pinski 2023-03-30 19:38:11 UTC
Created attachment 54793 [details]
Fixed up riscv64 testcase
Comment 5 Andrew Pinski 2023-03-30 19:39:17 UTC
Created attachment 54794 [details]
testcase for riscv32-elf

Here is a testcase which also fails for riscv32-elf. Note it only fails at -O0.
Comment 6 Andrew Pinski 2023-03-30 19:40:11 UTC
Oh if we add back the s0 case, it fails at -O1 and above too.
Comment 7 Andrew Pinski 2023-03-30 19:42:24 UTC
Created attachment 54795 [details]
testcase for riscv64-elf and riscv32-elf

This is new testcase fails for both riscv32 and riscv64 at -O0 and -O1. disabling s0 for -O0 too.
Comment 8 Andrew Pinski 2023-03-30 19:46:00 UTC
MIPS64 fails even for GCC 7:
t.c: In function ‘f’:
t.c:91:1: error: unable to find a register to spill
 }
 ^
t.c:91:1: error: this is the insn:
(insn 36 73 72 2 (set (reg:DI 200 [198])
        (plus:DI (reg:DI 201 [orig:194 t9.0_1 ] [194])
            (const_int 1 [0x1]))) "t.c":60 14 {*adddi3}
     (expr_list:REG_DEAD (reg:DI 201 [orig:194 t9.0_1 ] [194])
        (nil)))
t.c:91:1: internal compiler error: in assign_by_spills, at lra-assigns.c:1476
Comment 9 Andrew Pinski 2023-03-30 19:47:19 UTC
Even for pre-LRA with reload in GCC 4.7.0:
t.c: In function ‘f’:
t.c:91:1: note: unable to find a register to spill in class ‘GR_REGS’
t.c:91:1: note: this is the insn:
(insn 33 32 34 2 (set (reg:DI 198)
        (plus:DI (reg:DI 194 [ t9.0 ])
            (const_int 1 [0x1]))) t.c:60 11 {*adddi3}
     (expr_list:REG_DEAD (reg:DI 194 [ t9.0 ])
        (nil)))
t.c:91:1: internal compiler error: in spill_failure, at reload1.c:2120
unrecognized DWARF version in .debug_info at 6
0x70e2bf _fatal_insn
        /bajas/pinskia/src/toolchain-47/scripts/../src/gcc/rtl-error.c:106
0x705bab spill_failure
        /bajas/pinskia/src/toolchain-47/scripts/../src/gcc/reload1.c:2120
0x705bab find_reload_regs
        /bajas/pinskia/src/toolchain-47/scripts/../src/gcc/reload1.c:2046
0x705bab select_reload_regs
        /bajas/pinskia/src/toolchain-47/scripts/../src/gcc/reload1.c:2066
0x705bab reload
        /bajas/pinskia/src/toolchain-47/scripts/../src/gcc/reload1.c:993
0x65fe6e do_reload
        /bajas/pinskia/src/toolchain-47/scripts/../src/gcc/ira.c:3733
0x65fe6e rest_of_handle_reload
        /bajas/pinskia/src/toolchain-47/scripts/../src/gcc/ira.c:3824
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

So I am sure this is almost not a regression.