On 2/8/25 3:04 AM, Georg-Johann Lay wrote:
That test case from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389#c7
still ICEs with that change in http://gcc.gnu.org/r15-7428
pr116389-red.c: In function 'func':
pr116389-red.c:20:1: error: insn does not satisfy its constraints:
20 | }
| ^
(insn 27 69 28 5 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
(const_int 2 [0x2])) [4 %sfp+2 S4 A8])
(reg:SI 30 r30)) "pr116389-red.c":16:19 146 {*movsi_split}
(nil))
during RTL pass: postreload
pr116389-red.c:20:1: internal compiler error: in extract_constrain_insn,
at recog.cc:2783
Reason is that R30 is the last GPR and can hold HImode at most,
but due to a paradoxical subreg, there is r30:SI.
Bummer as that was the kind of scenario it's supposed to fix.
What did that insn look like before IRA and for whatever pseudo was in
that operand, what hard register did IRA think it should be allocated to?
jeff
