https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
_1 = a[b.1_14][7];
we "correctly" resolve b.1_14 to 1 based on range info which is
[-INF,-1] [1, +INF]. The thing is, the get_ref_base_and_extent code
cannot do anything with this range but adjusting max_size to 32
by taking [7] and the overall size of a[] (8 elements) into account.
The reverse-engineering of a constant array index falls apart when facing
with this kind of undefined behavior - and it's the checking code trying
to verify both implementations against each other that fails.
That said, it's
tree asize = TYPE_SIZE (TREE_TYPE (TREE_OPERAND (exp, 0)));
/* We need to adjust maxsize to the whole array bitsize.
But we can subtract any constant offset seen so far,
because that would get us outside of the array otherwise.
*/
if (known_size_p (maxsize)
&& asize
&& poly_int_tree_p (asize))
maxsize = wi::to_poly_offset (asize) - bit_offset;
that ends up constraining the access, but the resulting offset is
to a[1][3], and VN comes up with a[1][7].
