https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103818
--- Comment #6 from hubicka at kam dot mff.cuni.cz ---
> For 128-bit math, you can e.g. use poly_offset_int, which generally looks like
> a better type for these offsets and sizes (especially if they are counted in
> bits not bytes).
> Just to perform the <= comparison on the wider poly_offset_int, perhaps:
> --- gcc/ipa-modref-tree.cc.jj 2022-04-06 16:44:44.000000000 +0200
> +++ gcc/ipa-modref-tree.cc 2022-04-11 17:50:02.937784764 +0200
> @@ -380,9 +380,13 @@ modref_access_node::update2 (poly_int64
> new_max_size = max_size2;
> else
> {
> - new_max_size = max_size2 + offset2 - offset1;
> - if (known_le (new_max_size, max_size1))
> + poly_offset_int n = max_size2;
> + n += offset2;
> + n -= offset1;
> + if (known_le (n, max_size1))
> new_max_size = max_size1;
> + else
> + new_max_size = max_size2 + offset2 - offset1;
> }
>
> update (parm_offset1, offset1,
> (though, not sure how can you narrow that back to poly_int64).
> Though, the big question is what should one do with these overflows or
> underflows that aren't representable, update2 can't fail right now and the
> above still ICEs.
> Is there some way how to indicate it is an access to an unknown offset?
I sent patch for this (and plan to commit it today). One can set new_max_size
to -1 which means unknown/unlimited rnag on overflow. Underflow should
be impossible, since we always keep offsets/sizes nonnegative.
Honza
