https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118934
Bug ID: 118934
Summary: RISC-V: ICE: output_operand: invalid expression as
operand
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at ozlabs dot org
CC: kito.cheng at gmail dot com
Target Milestone: ---
We are hitting an ICE when trying to build 521.wrf_r in cpu2017:
internal compiler error: output_operand: invalid expression as operand
0x314e986 internal_error(char const*, ...)
source/gcc/gcc/diagnostic-global-context.cc:517
0x106d9c5 output_operand_lossage(char const*, ...)
source/gcc/gcc/final.cc:3196
0x106e3b7 output_asm_insn(char const*, rtx_def**)
source/gcc/gcc/final.cc:3530
0x1071e23 output_asm_insn(char const*, rtx_def**)
source/gcc/gcc/final.cc:3427
0x1071e23 final_scan_insn_1
source/gcc/gcc/final.cc:2846
0x10722ff final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
source/gcc/gcc/final.cc:2892
0x10723ec final_1
source/gcc/gcc/final.cc:1983
Looking closer, gcc is calling output_addr_const() from output_asm_insn() with
a %nN template and rtx_code = LT which is not handled.
It made me suspect the recent change in the RISC-V backend where the %N
modifier was changed to %n. Is there a reason we are re-using a generic
modifier (%nN)?
Backing these three patches out fixes the issue:
fcbb8456a58ba073d4d5b10fcb9057b6e9a100db ("RISC-V: Add new constraint R for
register even-odd pairs")
2a22db391d1819f6068aa43e63632b350a0b4bec ("RISC-V: Implment N modifier for
printing the register number rather than the register name")
192790e994c9e15949e694e0a52010001b291611 ("RISC-V: Rename internal operand
modifier N to n")
