From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8935E3858D28; Fri, 5 Nov 2021 12:48:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8935E3858D28 From: "hubicka at kam dot mff.cuni.cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/103073] [12 Regression] ICE in insert_access, at ipa-modref-tree.h:578 since r12-4401-gfecd145359fc981b Date: Fri, 05 Nov 2021 12:48:16 +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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 12:48:16 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103073 --- Comment #13 from hubicka at kam dot mff.cuni.cz --- > > diff --git a/gcc/ipa-modref-tree.h b/gcc/ipa-modref-tree.h > > index 9976e489697..1b51323175b 100644 > > --- a/gcc/ipa-modref-tree.h > > +++ b/gcc/ipa-modref-tree.h > > @@ -813,6 +818,20 @@ struct GTY((user)) modref_tree > >=20 > > bool changed =3D false; > >=20 > > + /* We may end up with max_size being less than size for accesses p= ast the > > + end of array. Those are undefined and safe to ignore. */ > > + if (a.range_info_useful_p () > > + && ((known_size_p (a.size) && known_size_p (a.max_size) > > + && known_lt (a.max_size, a.size)) >=20 > What about maybe_lt? Well, you should know the ICEing place and > whether it's sensitive to may or must ;) The range merging really went funny way because max_size =3D=3D 0 and I hope in that case we will always have known_lt. But indeed I may need to proofread the merging logic for maybes (I even do not know how to produce testcases with non-trivial polyints here). Maybe_lt is IMO not safe since it may make us to ignore stores that are valid on runtime (given that the variable length vector type is small enough to fit in max_size). >=20 > > + || (known_size_p (a.max_size) > > + && known_le (a.max_size, 0)))) >=20 > The known_size_p (a.max_size) && known_le (a.max_size, 0) should never > be true (there's only the -1 special value denoting 'unknown'). OK, I will add a sanity check since it seemed from the code earlier that negative values may happen (which would be indeed sloppy if it was happening). >=20 > Yeah, apart from the remark above. Thanks. I will update the patch. Honza >=20 > --=20 > You are receiving this mail because: > You are the assignee for the bug. > You are on the CC list for the bug.=