[Bug ipa/103818] [12 Regression] ICE: in insert, at ipa-modref-tree.c:591 since r12-3202-gf5ff3a8ed4ca9173

["hubicka at kam dot mff.cuni.cz" <gcc-bugzilla@gcc.gnu.org>]

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