On Wed, 2020-04-08 at 20:23 +0200, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on m68k (and another one Jeff mailed me
> privately on microblaze).
> The problem is that reload creates two DEBUG_INSNs with the same
> value of (plus:P (reg:P sp) (const_int 0)), we compute correctly the
> same hash value for them, but then don't find them in the cselib hash table,
> as rtx_equal_for_cselib_1 thinks it is different from (reg:P sp),
> and trigger an assertion failure that requires that from two different debug
> insns one doesn't add locations to VALUEs.
>
> The patch has two fixes for this, each fixes the ICE on both targets
> separately, but I think we want both.
>
> The cselib.c change ensures that rtx_equal_for_cselib_1 considers
> (value:P sp_derived_value) and (plus:P (reg:P sp) (const_int 0)) equivalent.
>
> The reload1.c change makes sure we don't create those bogus plus 0
> expressions. I understand the reasons for creating them, but they don't
> really apply to DEBUG_INSNs; we don't have validity matching there, all we
> care is that the expressions aren't arbitrarily deep, but it is just fine
> to fold x + 0 into just x in there.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, tested on the
> testcases with crosses to m86k-linux and microblaze-linux, ok for trunk?
>
> 2020-04-08 Jakub Jelinek <ja...@redhat.com>
>
> PR middle-end/94526
> * cselib.c (autoinc_split): Handle e->val_rtx being SP_DERIVED_VALUE_P
> with zero offset.
> * reload1.c (eliminate_regs_1): Avoid creating
> (plus (reg) (const_int 0)) in DEBUG_INSNs.
>
> * gcc.dg/pr94526.c: New test.
OK
jeff
>
