https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94526
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:d0cc1b79b39994c917abb23f71064bb39eedcc70 commit r10-7640-gd0cc1b79b39994c917abb23f71064bb39eedcc70 Author: Jakub Jelinek <ja...@redhat.com> Date: Wed Apr 8 21:23:58 2020 +0200 cselib, reload: Fix cselib ICE on m68k/microblaze [PR94526] 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. 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.
