[Bug target/111425] ia64: ICE in net/ipv4/fib_semantics.c:1621:1: internal compiler error: Segmentation fault

["tglozar at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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.