https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68302
--- Comment #13 from Steve Ellcey <sje at gcc dot gnu.org> ---
Thanks for the trace. I am still not sure I understand what is going on but I
wonder if you could try commenting out this code under the "case 'e'" code in
rtx_equal_for_cselib_1.
#if 0
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;
#endif
I think something is going wrong when we get here with x of:
(plus:SI (value/u:SI 60:60 @0x2335948/0x2391aa0)
(value/u:SI 15:4257 @0x2335678/0x2353978))
and y of:
(plus:SI (plus:SI (value/u:SI 60:60 @0x2335948/0x2391aa0)
(value/u:SI 15:4257 @0x2335678/0x2353978))
(value/u:SI 15:4257 @0x2335678/0x2353978))
I am not sure why that would send you into an infinite loop but
I think it might. Possibly due to having the value of 15 in the
expression twice. I think the reason you see it and I don't
might be related to new_cselib_val. It creates pointers
to values and I think GCC sorts things based on those pointers
at some point and the difference in how things are allocated
by pool_alloc in new_cselib_val might be the reason you get the
problem and I don't.
