Not sure if it's a dupe of bug #100241. Filing just in case. Observed when built libffi for sh4 target. Minimal example: // cat raw_api.c.c void ffi_raw_to_ptrarray(void); int ffi_call(void (*)(void *, void *), void*, void*, void*); void ffi_raw_call_cif(void *fn, void *rvalue) { void *avalue = __builtin_alloca(sizeof 0); ffi_raw_to_ptrarray(); ffi_call(ffi_raw_call_cif, fn, rvalue, avalue); } $ ./xgcc -B. -O2 -mlra -fexceptions -fPIE -fstack-protector -c raw_api.c.c -o raw_api.o raw_api.c.c: In function 'ffi_raw_call_cif': raw_api.c.c:8:1: error: unable to generate reloads for: 8 | } | ^ (call_insn 18 16 20 2 (parallel [ (call (mem:SI (symbol_ref:SI ("ffi_raw_to_ptrarray") [flags 0x41] <function_decl 0x7fc7ae93bb00 ffi_raw_to_ptrarray>) [0 ffi_raw_to_ptrarray S4 A32]) (const_int 0 [0])) (use (reg:SI 154 fpscr0)) (use (reg:SI 12 r12)) (clobber (reg:SI 146 pr)) (clobber (reg:SI 183)) ]) "raw_api.c.c":6:3 228 {call_pcrel} (expr_list:REG_CALL_DECL (symbol_ref:SI ("ffi_raw_to_ptrarray") [flags 0x41] <function_decl 0x7fc7ae93bb00 ffi_raw_to_ptrarray>) (nil)) (nil)) during RTL pass: reload raw_api.c.c:8:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:4132 0x7fc7aea9287c __libc_start_main ../csu/libc-start.c:332 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Using built-in specs. COLLECT_GCC=./xgcc Target: sh4-unknown-linux-gnu Configured with: ../gcc/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=sh4-unknown-linux-gnu --prefix=/home/slyfox/dev/git/gcc-sh4-ice/../gcc-sh4-installed --with-sysroot=/usr/sh4-unknown-linux-gnu --disable-bootstrap --enable-languages=c --disable-nls CFLAGS=-O0 CXXFLAGS=-O0 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20210526 (experimental) (GCC)
(In reply to Sergei Trofimovich from comment #0) > Not sure if it's a dupe of bug #100241. Filing just in case. Probably different: it's a different target and different instruction.
The description says: gcc version 12.0.0 20210526 (experimental) (GCC) so is this about GCC 12 or GCC 11? What version worked fine (why's this marked as regression?)
(In reply to Richard Biener from comment #2) > The description says: > > gcc version 12.0.0 20210526 (experimental) (GCC) > > so is this about GCC 12 or GCC 11? What version worked fine (why's this > marked as regression?) My apologies. It should be a gcc-11 regression. More gcc versions outputs: $ /tmp:sh4-unknown-linux-gnu-gcc-10.3.0 -O2 -mlra -fexceptions -fPIE -fstack-protector -c a.c <ok> $ sh4-unknown-linux-gnu-gcc-11.1.0 -O2 -mlra -fexceptions -fPIE -fstack-protector -c a.c a.c: In function 'ffi_raw_call_cif': a.c:9:1: error: unable to generate reloads for: 9 | } | ^ (call_insn 18 16 20 2 (parallel [ (call (mem:SI (symbol_ref:SI ("ffi_raw_to_ptrarray") [flags 0x41] <function_decl 0x7f3c4e947b00 ffi_raw_to_ptrarray>) [0 ffi_raw_to_ptrarray S4 A32]) (const_int 0 [0])) (use (reg:SI 154 fpscr0)) (use (reg:SI 12 r12)) (clobber (reg:SI 146 pr)) (clobber (reg:SI 183)) ]) "a.c":7:3 228 {call_pcrel} (expr_list:REG_CALL_DECL (symbol_ref:SI ("ffi_raw_to_ptrarray") [flags 0x41] <function_decl 0x7f3c4e947b00 ffi_raw_to_ptrarray>) (nil)) (nil)) during RTL pass: reload a.c:9:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:4138 0x7f3c4ea9e7ac __libc_start_main ../csu/libc-start.c:332 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions.
Bisected down to r11-4577 commit 44fbc9c6e02ca5b8f98f25b514ed7588e7ba733d Author: Vladimir N. Makarov <vmakarov@redhat.com> Date: Fri Oct 30 15:05:22 2020 -0400 Take insn scratch RA requirements into account in IRA. The patch changes insn scratches which require registers for all insn alternatives (in other words w/o X constraint in scratch constraint string). This is done before IRA staring its work. LRA still continue to change the rest scratches (with X constraint and in insn created during IRA) into pseudos. As before the patch at the end of LRA work, spilled scratch pseudos (for which X constraint was chosen) changed into scratches back.
GCC 11.2 is being released, retargeting bugs to GCC 11.3
Trying to understand why rejection happens: -fdump-rtl-all-slim 295r.reload says: Choosing alt 0 in insn 12: (0) =r (1) %0 (2) rI08 {*addsi3_compact_lra} alt=0: No input/output reload -- refuse ... 12: r15:SI=r15:SI-0x4 I'm surprised the same (hard) reg is used in source and destination in insn 12. *addsi3_compact_lra hints at special assumptions about it: ;; The *addsi3_compact is made an insn_and_split and accepts actually ;; impossible constraints to make LRA's register elimination work well on SH. ;; The problem is that LRA expects something like ;; (set rA (plus rB (const_int N))) ;; to work. We can do that, but we have to split out an additional reg-reg ;; copy or constant load before the actual add insn. ;; Use u constraint for that case to avoid the invalid value in the stack ;; pointer. ;; This also results in better code when LRA is not used. However, we have ;; to use different sets of patterns and the order of these patterns is ;; important. ;; In some cases the constant zero might end up in operands[2] of the ;; patterns. We have to accept that and convert it into a reg-reg move. (define_insn_and_split "*addsi3_compact_lra" [(set (match_operand:SI 0 "arith_reg_dest" "=r,&u") (plus:SI (match_operand:SI 1 "arith_reg_operand" "%0,r") (match_operand:SI 2 "arith_or_int_operand" "rI08,rn")))] "TARGET_SH1 && sh_lra_p () && (! reg_overlap_mentioned_p (operands[0], operands[1]) || arith_operand (operands[2], SImode))" "@ add %2,%0 #" "&& reload_completed && ! reg_overlap_mentioned_p (operands[0], operands[1])" [(set (match_dup 0) (match_dup 2)) (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 1)))] { /* Prefer 'mov r0,r1; add #imm8,r1' over 'mov #imm8,r1; add r0,r1' */ if (satisfies_constraint_I08 (operands[2])) std::swap (operands[1], operands[2]); } [(set_attr "type" "arith")])
GCC 11.3 is being released, retargeting bugs to GCC 11.4.
GCC 11.4 is being released, retargeting bugs to GCC 11.5.
It's unclear whether this was fixed or not, re-targeting and adjusting possible regression status. Keep WAITING. The 11 branch is closed now.