From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2CF503858283; Mon, 5 Feb 2024 09:57:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2CF503858283 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1707127051; bh=HknQMl8C7P55iV28+eWa9P0zDNvnbP9kCkunCUep1pk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CQCAQcrNat/XeV6koCbEYlzt2hmf4NOpj+KW2PEVu0dMxzUFmehfMOWdKMwNI7mzP vUvJT2ajK0uhKko+376mg2XE+S2+iWcLG/eIKLYeTHsA1u/ueKFyTtmLkbSqSLDVG/ WsAf+uEvOgTj6kHMj1HIpc5CIZtvhbHgk3kvhn5k= From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above Date: Mon, 05 Feb 2024 09:57:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113735 --- Comment #2 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #1) > Slightly tweaked, still -O1: > char b; > void bar (void); >=20 > void > foo (_BitInt(6110) j) > { > for (;;) > { > _BitInt(10) k =3D b % j; > for (j =3D 6; j; --j) > if (k) > bar (); > } > } >=20 > The ICE is in on: > 721 if (!m_equiv[bb->index]) > because bb->index is larger than m_equiv size. > The bitint lowering pass works by walking the IL and replacing some > statements in there with lowered code, which can involve new basic blocks > (either through splitting existing blocks or creating fresh new ones) and > the like. And asks the ranger about range of statements during that. > Is that something that ranger doesn't/can't support? > So, would I need to ensure to find out what ranges I'll need before making > any changes, > ask for them, remember them somewhere on the side and then use them during > the transformations? We're generally OK with changing IL, if the semantic of the statement doesn= 't change. For example, you couldn't change the meaning of a statement to mean something totally different, as that would invalidate the cached value of t= he resulting SSA. The cache was tweaked in the last release or so to handle growing SSA names. I'm not totally sure on changing BBs, as VRP didn't add BB's in flight, IIR= C.=20 But I do see code in the relation oracle handling a change in the BB count: void equiv_oracle::limit_check (basic_block bb) { int i =3D (bb) ? bb->index : last_basic_block_for_fn (cfun); if (i >=3D (int)m_equiv.length ()) m_equiv.safe_grow_cleared (last_basic_block_for_fn (cfun) + 1); } Interestingly, this function is never used. Andrew, was this an oversight? The attached patch seems to fix the problem, and it looks like all other dereferences of m_equiv[] have a suitable check, or are looking for things already known to have an entry. Andrew would know for sure. diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc index 27f9ad61c0e..619ee5f0867 100644 --- a/gcc/value-relation.cc +++ b/gcc/value-relation.cc @@ -718,6 +718,7 @@ equiv_oracle::add_equiv_to_block (basic_block bb, bitmap equiv_set) // Check if this is the first time a block has an equivalence added. // and create a header block. And set the summary for this block. + limit_check (bb); if (!m_equiv[bb->index]) { ptr =3D (equiv_chain *) obstack_alloc (&m_chain_obstack,=