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.