https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94526
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aoliva at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We have before var-tracking:
(insn/f:TI 33 6 7 2 (parallel [
(set/f (reg/f:SI 14 %a6)
(plus:SI (reg/f:SI 15 %sp)
(const_int -4 [0xfffffffffffffffc])))
(set/f (mem/c:SI (plus:SI (reg/f:SI 15 %sp)
(const_int -4 [0xfffffffffffffffc])) [5 S4 A8])
(reg/f:SI 14 %a6))
(set/f (reg/f:SI 15 %sp)
(plus:SI (reg/f:SI 15 %sp)
(const_int -132 [0xffffffffffffff7c])))
]) "pr94526.c":13:1 417 {*link}
(nil))
(debug_insn 7 33 8 2 (var_location:SI p1 (plus:SI (reg/f:SI 15 %sp)
(const_int 0 [0]))) "pr94526.c":15:3 -1
(nil))
(debug_insn 8 7 9 2 (debug_marker) "pr94526.c":6:3 -1
(nil))
(debug_insn 9 8 10 2 (var_location:SI a (plus:SI (reg/f:SI 15 %sp)
(const_int 0 [0]))) "pr94526.c":6:13 -1
(nil))
The first insn in this snippet is fp_setter after which we forget the sp value
so that it is not related to the hard frame pointer, thus the new
SP_DERIVED_VALUE_P VALUE has location of %sp and setting_insn NULL.
Then we have two debug insns with %sp + 0 due to reload (unnecessary).
And when processing those, we properly compute the hash of %sp + 0 the same as
hash of %sp, but rtx_equal_for_cselib_1 doesn't figure out the equality, we
create each time a different VALUE, due to the equivalency insert locs into the
%sp VALUE though and ICE on an assert that two different DEBUG_INSNs don't add
locs to the same VALUE (admittedly a weird assert).
I have two fixes, teach rtx_equal_for_cselib_1 to deal with this + 0 case, and
adjust reload so that in DEBUG_INSNs it doesn't add this useless stuff, both
fix the ICE.
