https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154
Bug ID: 104154
Summary: [12 Regression] Another ICE due to recent ifcvt
changes
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
Created attachment 52251
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52251&action=edit
Testcase
I didn't bisect this to the exact change, but I'm highly confident this is
another issue with the recent ifcvt work.
On arc-elf, compile the attached testcase with -O2 to trigger an assert in the
arc backend:
during RTL pass: ce1
../../../../../../..//newlib-cygwin/newlib/libc/stdlib/mprec.c: In function
‘__multiply’:
../../../../../../..//newlib-cygwin/newlib/libc/stdlib/mprec.c:416:1: internal
compiler error: in gen_compare_reg, at config/arc/arc.cc:2259
0x17e7fe6 gen_compare_reg(rtx_def*, machine_mode)
/home/jlaw/test/gcc/gcc/config/arc/arc.cc:2259
0x1ded7ab gen_movsicc(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/home/jlaw/test/gcc/gcc/config/arc/arc.md:1621
0x1169216 rtx_insn* insn_gen_fn::operator()<rtx_def*, rtx_def*, rtx_def*,
rtx_def*>(rtx_def*, rtx_def*, rtx_def*, rtx_def*) const
/home/jlaw/test/gcc/gcc/recog.h:407
0x1168b00 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/home/jlaw/test/gcc/gcc/optabs.cc:7962
0x1168df6 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/home/jlaw/test/gcc/gcc/optabs.cc:7993
0x1160699 emit_conditional_move_1
/home/jlaw/test/gcc/gcc/optabs.cc:5030
0x1160475 emit_conditional_move(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, machine_mode)
/home/jlaw/test/gcc/gcc/optabs.cc:4980
0x1f7ec9f noce_emit_cmove
/home/jlaw/test/gcc/gcc/ifcvt.cc:1753
0x1f82910 try_emit_cmove_seq
/home/jlaw/test/gcc/gcc/ifcvt.cc:3179
0x1f82ec1 noce_convert_multiple_sets
/home/jlaw/test/gcc/gcc/ifcvt.cc:3396
0x1f83682 noce_process_if_block
/home/jlaw/test/gcc/gcc/ifcvt.cc:3616
[ ... ]
At first glance this appears to be a problem with feeding an existing
comparison back through the target bits. The arc backend simply isn't prepared
to deal with that. But it may be a higher level issue. Anyway, it's clearly a
regression relative to gcc-12 as the arc port will no longer build newlib.
