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 9D4DA385C325; Mon, 11 Apr 2022 16:00:04 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9D4DA385C325
From: "jakub at gcc dot gnu.org" <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: Mon, 11 Apr 2022 16:00:03 +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: jakub at gcc dot gnu.org
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: cc
Message-ID: <bug-103818-4-omIBgiO7Ol@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: Mon, 11 Apr 2022 16:00:04 -0000

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

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 l=
ike
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;
     }

   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?=