http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49390
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-06-13 12:36:58 UTC --- Blindly ignoring MEM_EXPR or other attributes looks very wrong to me. Guess in some cases it could return true even when MEM_ATTRS aren't identical, but they'd need to have the same behavior during alias analysis at least, or one of the attrs would need to be a superset of the other ones (but then it would need to be ensured that the callers pick up the superset instead of the other MEM_ATTRS). On this particular testcase, exp_equiv_p returns 1 for_gcse on MEM_EXPRs c_4(D)->s1+0 and c_1->s1+0 (other attributes are the same). c_1 is: # c_1 = PHI <[rh712480.i : 41:7] [rh712480.i : 41] &e(2), c_4(D)(4), c_4(D)(5)> and e is an automatic variable. If GCSE thinks those two MEMs are equivalent (one, c_4(D) based is present e.g. in the else branch of the if (c == 0) stmt, c_1 based afterwards) and merges those two into the one that has c_4(D)->s1 in it instead of c_1->s1, then aliasing oracle will see c_4(D)->s1 MEM_EXPR and e.s1 MEM_EXPR and will say that they can't alias (while for c_1->s1 and e.s1 they could and do). I think such a change was ok in 4.4 and earlier era, where alias oracle hasn't been used to disambiguate RTL MEMs, but there also it would be NULL -> s1 rather than c_1 -> s1 etc.
