https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425
--- Comment #8 from Tomáš Glozar <tglozar at gmail dot com> ---
It looks like somehow a value RTX with rt_cselib set to NULL gets into the
hashmap:
(gdb) f 1
#1 rtx_equal_for_cselib_1 (x=0x2674608, y=0x26747f8,
memmode=memmode@entry=E_VOIDmode, depth=depth@entry=1)
at ../../gcc/cselib.cc:963
963 cselib_val *e = canonical_cselib_val (CSELIB_VAL_PTR (x));
(gdb) p debug_rtx(x)
(value:DI
Program received signal SIGSEGV, Segmentation fault.
0x0000000000a92f96 in rtx_writer::print_rtx_operand_code_0
(this=0x7fffffff64c0, in_rtx=0x2674608, idx=0)
at ../../gcc/print-rtl.cc:318
318 fprintf (m_outfile, " %u:%u", val->uid, val->hash);
Going one level up:
(gdb) p debug_rtx(y)
(subreg:SI (value/u:DI 264:376 @0x26747f8/0x2666068) 0)
$1 = void
(gdb) p debug_rtx(x)
(subreg:SI (value:DI
Program received signal SIGSEGV, Segmentation fault.
Not sure how this is related to 5fc4d3e1837, as I understand it, it should only
affect single-bit values, here it is a DI value. I am not familiar with the
algorithm, so proceeding further in finding the cause it hard for me.
Perhaps someone who knows the algorithm has an idea why that field is NULL.
