https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67355
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aoliva at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Breakpoint 5, rtx_equal_for_cselib_1 (x=0x7ffff6a152b8, y=0x7ffff6a152a0,
memmode=VOIDmode) at /space/rguenther/src/svn/gcc-5-branch/gcc/cselib.c:871
871 if (REG_P (x) || MEM_P (x))
(gdb) p debug_rtx (x)
(plus:SI (value/u:SI 56:56 @0x2275a78/0x22c6a40)
(value/u:SI 29:4257 @0x22757f0/0x22c5b60))
$1 = void
(gdb) p debug_rtx (y)
(plus:SI (plus:SI (value/u:SI 56:56 @0x2275a78/0x22c6a40)
(value/u:SI 29:4257 @0x22757f0/0x22c5b60))
(value/u:SI 29:4257 @0x22757f0/0x22c5b60))
and we run into
case 'e':
if (i == 1
&& targetm.commutative_p (x, UNKNOWN)
&& rtx_equal_for_cselib_1 (XEXP (x, 1), XEXP (y, 0), memmode)
&& rtx_equal_for_cselib_1 (XEXP (x, 0), XEXP (y, 1), memmode))
return 1;
if (! rtx_equal_for_cselib_1 (XEXP (x, i), XEXP (y, i), memmode))
return 0;
recursing with i == 0
rtx_equal_for_cselib_1 (x=0x2275a78, y=0x7ffff6a152b8, memmode=VOIDmode)
at /space/rguenther/src/svn/gcc-5-branch/gcc/cselib.c:871
871 if (REG_P (x) || MEM_P (x))
(gdb) p debug_rtx (x)
(value/u:SI 56:56 @0x2275a78/0x22c6a40)
$5 = void
(gdb) p debug_rtx (y)
(plus:SI (value/u:SI 56:56 @0x2275a78/0x22c6a40)
(value/u:SI 29:4257 @0x22757f0/0x22c5b60))
values for x we try from the canonical location list:
(value/u:SI 57:8708 @0x2275a90/0x22c6a70) - skipped
(plus:SI (plus:SI (value/u:SI 56:56 @0x2275a78/0x22c6a40)
(value/u:SI 29:4257 @0x22757f0/0x22c5b60))
(value/u:SI 29:4257 @0x22757f0/0x22c5b60))
oops, that's our original 'y' expression! So we managed to recurse with
the same arguments but swapped.
But values also look somewhat non-sensical as we basically have
(plus (plus value1 value2) value2) == value1 which can only be true
for value2 == 0.
I don't know anything about CSELIB or var-tracking so I'll defer to somebody
else devising a way to fix the invalid(?) value or avoid recursions of this
style.
The problem is likely only latent on trunk.
