https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103818
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |rsandifo at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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?
