I get the following internal compiler error after the addition of support of XTheadCondMov in commit "basepoints/gcc-13-6686-g8e7ffe126de" when using the following compile options: "-O2 -mcpu=sifive-u74" or "-O1 -mcpu-sifive-u74" with a riscv64-unknown-linux-gnu compiler. The bug is still present on a recent master (basepoints/gcc-14-540-gb7fe38c14e5) ./cross/riscv64/bin/riscv64-unknown-linux-gnu-gcc -O1 -mcpu=sifive-u74 -c ./qgridlayoutengine.ii ./qgridlayoutengine.ii: In function 'void e()': ./qgridlayoutengine.ii:14:1: error: unrecognizable insn: 14 | } | ^ (insn 12 11 13 2 (set (reg:DI 137) (if_then_else:DI (ne:DF (reg:DF 139) (reg:DF 140)) (reg:DI 141) (reg:DI 143))) -1 (nil)) during RTL pass: vregs ./qgridlayoutengine.ii:14:1: internal compiler error: in extract_insn, at recog.cc:2791 0x82e78d _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /home/spotvin/work/gcc-13.1.0-failure/cross/gcc/gcc/rtl-error.cc:108 0x82e7a9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /home/spotvin/work/gcc-13.1.0-failure/cross/gcc/gcc/rtl-error.cc:116 0x82d133 extract_insn(rtx_insn*) /home/spotvin/work/gcc-13.1.0-failure/cross/gcc/gcc/recog.cc:2791 0xe80f9d instantiate_virtual_regs_in_insn /home/spotvin/work/gcc-13.1.0-failure/cross/gcc/gcc/function.cc:1611 0xe80f9d instantiate_virtual_regs /home/spotvin/work/gcc-13.1.0-failure/cross/gcc/gcc/function.cc:1985 0xe80f9d execute /home/spotvin/work/gcc-13.1.0-failure/cross/gcc/gcc/function.cc:2034 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Here's the code snippet that can reproduce the issue struct a { void b(); } boxes; struct { a boxes; } c; double d; void e() { bool f(d); for (;;) { a &g = f ? c.boxes : boxes; g.b(); } } The output of gcc -v is COLLECT_GCC=./cross/riscv64/bin/riscv64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/home/spotvin/work/gcc-13.1.0-failure/cross/riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/13.0.1/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /home/spotvin/work/gcc-13.1.0-failure/cross/riscv-gnu-toolchain/build/../../gcc/configure --target=riscv64-unknown-linux-gnu --prefix=/home/spotvin/work/gcc-13.1.0-failure/cross/riscv-gnu-toolchain/build/../../riscv64 --with-sysroot=/home/spotvin/work/gcc-13.1.0-failure/cross/riscv-gnu-toolchain/build/../../riscv64/sysroot --with-pkgversion=g8e7ffe126de --with-system-zlib --enable-shared --enable-tls --enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap --src=/home/spotvin/work/gcc-13.1.0-failure/cross/gcc --disable-multilib --with-abi=lp64d --with-arch=rv64imafdc --with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2 -mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2 -mcmodel=medlow' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.1 20230315 (experimental) (g8e7ffe126de) I used a cross-compiler to speedup the bisection of the commit where the issue appeared but I got the same behavior with a native gcc: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-unknown-linux-gnu/13/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-13.1.0-r1/work/gcc-13.1.0/configure --host=riscv64-unknown-linux-gnu --build=riscv64-unknown-linux-gnu --prefix=/usr --bindir=/usr/riscv64-unknown-linux-gnu/gcc-bin/13 --includedir=/usr/lib/gcc/riscv64-unknown-linux-gnu/13/include --datadir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13 --mandir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13/man --infodir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13/info --with-gxx-include-dir=/usr/lib/gcc/riscv64-unknown-linux-gnu/13/include/g++-v13 --with-python-dir=/share/gcc-data/riscv64-unknown-linux-gnu/13/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 13.1.0-r1 p1' --with-gcc-major-version-only --disable-esp --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --with-abi=lp64d --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --without-isl --enable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.1.0 (Gentoo 13.1.0-r1 p1)
Slightly simpler reproduction program void b() { double c; for(;;) { void e(void*); e(c ? 0 : b); } } Which give the following error gcc -O2 -mcpu=sifive-u74 -c libimagequant.c.i libimagequant.c.i: In function ‘b’: libimagequant.c.i:7:1: error: unrecognizable insn: 7 | } | ^ (insn 7 6 8 2 (set (reg:DI 137) (if_then_else:DI (eq:DF (reg/v:DF 135 [ c ]) (reg:DF 138)) (reg:DI 139) (const_int 0 [0]))) -1 (nil)) during RTL pass: vregs libimagequant.c.i:7:1: internal compiler error: in extract_insn, at recog.cc:2791 0x27546d _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/rtl-error.cc:108 0x27548f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/rtl-error.cc:116 0x6abbff extract_insn(rtx_insn*) /usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/recog.cc:2791 0x4a790b instantiate_virtual_regs_in_insn /usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/function.cc:1611 0x4a790b instantiate_virtual_regs /usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/function.cc:1985 0x4a790b execute /usr/src/debug/sys-devel/gcc-13.1.0-r1/gcc-13.1.0/gcc/function.cc:2034 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions.
*** Bug 110095 has been marked as a duplicate of this bug. ***
Di fixed this a while back. Bisection points to this: commit 55914b016de8c8514c58eb59822677a69e44135c Author: Die Li <lidie@eswincomputing.com> Date: Fri May 19 23:00:13 2023 -0600 Fix riscv_expand_conditional_move. Two issues have been observed in current riscv_expand_conditional_move implementation. 1. Before introduction of TARGET_XTHEADCONDMOV, op0 of comparision expression is used for mode comparision with word_mode, but after TARGET_XTHEADCONDMOV megered with TARGET_SFB_ALU, dest of if-then-else is used for mode comparision with word_mode, and from md file mode of dest is DI or SI which can be different with word_mode in RV64. 2. TARGET_XTHEADCONDMOV cannot be generated when the mode of the comparison is E_VOID.
I confirm that the error is not present anymore when applying 55914b016de8c8514c58eb59822677a69e44135c on 13.1.0 and 13.2.1. Thanks!