https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124608
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #13)
> Possibly
>
> diff --git a/gcc/ipa-modref-tree.cc b/gcc/ipa-modref-tree.cc
> index 5d91dc44241..c147ba43ecc 100644
> --- a/gcc/ipa-modref-tree.cc
> +++ b/gcc/ipa-modref-tree.cc
> @@ -96,7 +96,7 @@ modref_access_node::contains (const modref_access_node &a)
> const
> && (!known_size_p (a.size)
> || !known_le (size, a.size)))
> return false;
> - if (known_size_p (max_size))
> + if (known_size_p (max_size) && known_size_p (a.max_size))
> return known_subrange_p (poly_offset_int::from (a.offset, SIGNED)
> + aoffset_adj, a.max_size,
> poly_offset_int::from (offset, SIGNED),
>
> at least could be validated that it doesn't happen by asserting known_size_p
> (a.max_size). I'll try that. Because known_subrange_p will test
> known_size_p on a.max_size, so this might cause odd differences in behavior
> of ::contains where the fallback with
>
> else
> return known_le (poly_offset_int::from (offset, SIGNED),
> poly_offset_int::from (a.offset, SIGNED)
> + aoffset_adj);
>
> would have returned true instead of false because of !known_size_p
> (a.max_size).
That said, known_subrange_p does not seem to handle [A0, B0] < [A0, unknown(
in the same conservative way than ::contains seems to.
But it also means ::contains should eventually return true iff
_either_ known_subrange_p _or_ known_le? Though ::merge has
/* We assume that containment was tested earlier. */
gcc_checking_assert (!contains (a) && !a.contains (*this));
this doesn't work with the known_le fallback I think. So I wonder how
unknown max_size is handled in general.
