From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 531F13858C56; Tue, 12 Apr 2022 10:50:46 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 531F13858C56
From: "hubicka at kam dot mff.cuni.cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/103818] [12 Regression] ICE: in insert, at
 ipa-modref-tree.c:591 since r12-3202-gf5ff3a8ed4ca9173
Date: Tue, 12 Apr 2022 10:50:45 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at kam dot mff.cuni.cz
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-103818-4-dsTsJIBKO8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-103818-4@http.gcc.gnu.org/bugzilla/>
References: <bug-103818-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2022 10:50:46 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103818

--- 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 <=3D 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 =3D max_size2;
>    else
>      {
> -      new_max_size =3D max_size2 + offset2 - offset1;
> -      if (known_le (new_max_size, max_size1))
> +      poly_offset_int n =3D max_size2;
> +      n +=3D offset2;
> +      n -=3D offset1;
> +      if (known_le (n, max_size1))
>         new_max_size =3D max_size1;
> +      else
> +       new_max_size =3D max_size2 + offset2 - offset1;
>      }
>=20
>    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_s=
ize
to -1 which means unknown/unlimited rnag on overflow.  Underflow should
be impossible, since we always keep offsets/sizes nonnegative.

Honza=