https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 15 Nov 2019, wilco at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462 > > --- Comment #19 from Wilco <wilco at gcc dot gnu.org> --- > > for this. Which "obviously" doesn't alias with the stack based address > > because that one is "unique_base_value_p" (address:SI -3) so we win here: > > > > 2229 if (unique_base_value_p (x_base) || unique_base_value_p (y_base)) > > 2230 return 0; > > > > now I wonder where that LANCHOR thing comes from. arm folks? > > Well when you do: > > int *p = &local + ((intptr_t)&global & 3); > > then you get the above expression when the global is addressed via an anchor. > > But whether or not a target uses anchors doesn't matter - the example still > fails with -O1 -fno-section-anchors. > > So I'm wondering whether the issue is in the special code that tries to > interpret an AND in an address, and mistakes the base as the symbol_ref > eventhough the real base is sfp. OK, so if it is not special to section anchors then it's kind-of a duplicate of PR49330 - find_base_term is fragile on RTL since we've lost the distinction between pointer and integer and thus do not know which one is the base and which the offset. But yes, the AND handling is "fishy" - it's intended to look through aligning ANDs but here we extract misalignment. I suppose we're looking for ANDs with a mask operand that doesn't have its least significant bit set and with all set bits spanning a contiguous region large enough for representing an actual object address. For this particular testcase INTVAL (XEXP (x, 1)) != 0 could be amended with INTVAL (XEXP (x, 1)) & 1 ! = 0. See the PR for endless endevours trying to "fix" this without removing the bogus code completely. Index: gcc/alias.c =================================================================== --- gcc/alias.c (revision 278293) +++ gcc/alias.c (working copy) @@ -2024,7 +2024,11 @@ find_base_term (rtx x, vec<std::pair<cse } case AND: - if (CONST_INT_P (XEXP (x, 1)) && INTVAL (XEXP (x, 1)) != 0) + /* Look through aligning ANDs. And AND with zero or one with + the LSB set isn't one (see for example PR92462). */ + if (CONST_INT_P (XEXP (x, 1)) + && INTVAL (XEXP (x, 1)) != 0 + && (INTVAL (XEXP (x, 1)) & 1) == 0) return find_base_term (XEXP (x, 0), visited_vals); return 0; seems to fix this particular instance.
