https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81874
--- Comment #6 from zwzhangwen.zhang at huawei dot com ---
I think this bug exists and hides.The reason is that trunc_int_for_mode will
check newval replacing oldval with CONST_INT in combine pass, but for
0x80000000，the result of trunc_int_for_mode is 0xfffffff80000000 and is not
equal to 0x80000000. So gcc assert as follows:
/* Sanity check that we're replacing oldval with a CONST_INT
that is a valid sign-extension for the original mode. */
gcc_assert (INTVAL (newval)
== trunc_int_for_mode (INTVAL (newval), GET_MODE (oldval)));
gcc tries to combine two insns as follows:
(insn 4018 4017 4019 226 (set (reg:SI 2681)
(const_int -2147483648 [0xffffffff80000000])) ...
(expr_list:REG_EQUAL (const_int 2147483648 [0x80000000])
(nil))
(insn 4019 4018 12 226 (set (mem:SI (reg/f:SI 270 [ pretmp_609 ]) [1
*pretmp_609+0 S4 A32])
(reg:SI 2681)) ...
(nil))
The first time gcc try to combine them but fail. The second time gcc find equal
reg_note and continue to combine them then gcc assert.
Because many optimizing pass can affect insn list, many patch can hide the bug.
Hope your help to resolve the problem.
