[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips

[sje at gcc dot gnu.org]

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.