https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81278
--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, I believe this has been introduced in r244974 from PR71433.
We have 5 asserts for SSA_NAME 66 in the problematic function:
(gdb) p *asserts.m_auto.m_vecdata[0]
$49 = {bb = <basic_block 0x7fffd64140d0 (37)>, e = <edge 0x7fffd3753230 (15 ->
37)>, si = {ptr = 0x7fffd37523c0, seq = 0x7fffd6407588,
bb = <basic_block 0x7fffd6407548 (15)>}, comp_code = EQ_EXPR, val =
<ssa_name 0x7fffd7ce8090>, expr = <ssa_name 0x7fffd7ce46c0>,
next = 0x3a29bc0}
(gdb) p *asserts.m_auto.m_vecdata[1]
$50 = {bb = <basic_block 0x7fffd64140d0 (37)>, e = <edge 0x7fffd3753118 (13 ->
37)>, si = {ptr = 0x7fffd3752230, seq = 0x7fffd6407450,
bb = <basic_block 0x7fffd6407410 (13)>}, comp_code = EQ_EXPR, val =
<addr_expr 0x7fffdd5211c0>, expr = <ssa_name 0x7fffd7ce46c0>,
next = 0x3a29c10}
(gdb) p *asserts.m_auto.m_vecdata[2]
$51 = {bb = <basic_block 0x7fffd6407478 (14)>, e = <edge 0x7fffd3753150 (13 ->
14)>, si = {ptr = 0x7fffd3752230, seq = 0x7fffd6407450,
bb = <basic_block 0x7fffd6407410 (13)>}, comp_code = NE_EXPR, val =
<addr_expr 0x7fffdd5211c0>, expr = <ssa_name 0x7fffd7ce46c0>,
next = 0x3a29c60}
(gdb) p *asserts.m_auto.m_vecdata[3]
$52 = {bb = <basic_block 0x7fffd64140d0 (37)>, e = <edge 0x7fffd37530a8 (12 ->
37)>, si = {ptr = 0x7fffd37521e0, seq = 0x7fffd6407178,
bb = <basic_block 0x7fffd6407138 (12)>}, comp_code = EQ_EXPR, val =
<addr_expr 0x7fffdd52c2a0>, expr = <ssa_name 0x7fffd7ce46c0>,
next = 0x3a29cb0}
(gdb) p *asserts.m_auto.m_vecdata[4]
$53 = {bb = <basic_block 0x7fffd6407410 (13)>, e = <edge 0x7fffd37530e0 (12 ->
13)>, si = {ptr = 0x7fffd37521e0, seq = 0x7fffd6407178,
bb = <basic_block 0x7fffd6407138 (12)>}, comp_code = NE_EXPR, val =
<addr_expr 0x7fffdd52c2a0>, expr = <ssa_name 0x7fffd7ce46c0>, next = 0x0}
and the new compare_assert_loc first sorts on !a->e != !b->e, then on
destination index (both are fine for -fcompare-debug), but then
on iterative_hash_expr (a->expr, iterative_hash_expr (a->val, 0)) vs.
iterative_hash_expr (b->expr, iterative_hash_expr (b->val, 0));
which is not ok, because the two val values are ADDR_EXPR of a helper variable
which has different DECL_UID between -g and -g0.
Let me try to fix this by doing another qsort afterwards which ignores the hash
and just uses edge indexes.
