From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2614D3858C33; Mon, 1 Aug 2022 13:58:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2614D3858C33 From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/106495] [13 Regression] Build fails gcc/tree-ssa-threadbackward.cc:22: gcc/vec.h:890:19: error: array subscript 4294967294 is above array bounds of 'basic_block_def* [1]' [-Werror=array-bounds] Date: Mon, 01 Aug 2022 13:58:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.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: Mon, 01 Aug 2022 13:58:08 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106495 --- Comment #9 from Aldy Hernandez --- (In reply to Richard Biener from comment #7) > So in this case we have >=20 > (gdb) p *path->m_vec->m_vecdata[0] > $106 =3D {e =3D 7)>, type =3D EDGE_COPY_SRC_BLOCK} > (gdb) p *path->m_vec->m_vecdata[1] > $107 =3D {e =3D 9)>, type =3D EDGE_COPY_SRC_BLOCK} > (gdb) p *path->m_vec->m_vecdata[2] > $108 =3D {e =3D 10)>, type =3D EDGE_NO_COPY_SRC_BL= OCK} >=20 > and the last edge (9 -> 10) is known to be never executed: >=20 > [local count: 435262723]: > _3 =3D MEM [(struct basic_block_def * const &)_21].m_vecdata= [_2]; > _4 =3D iftmp.22_23 + 4294967295; > if (_4 >=3D _20) > goto ; [0.00%] >=20 > we've isolated a quite "unlikely" combo here. We could go for generalizi= ng > the earlier patch, disqualifying the path if any of the edges involved. >=20 > Note that profitable_path_p only gets to see 5->7->9, strangely not the > final ->10? It look like only maybe_register_path () via find_taken_edge > will ask profitable_path_p _again_ (but with taken_edge now set)!? profitable_path_p gets called during path discovery (find_paths_to_names), = so we don't have complete info. The idea is that if a path so far is unprofitable, no sense looking further in that particular direction. In reality Jeff and I ran into a testcase where a partial path was not profita= ble, but a path with some extra blocks was. There's a PR somewhere for it, but = it happened so infrequent, that this heuristic was good enough. >=20 > So the "cheapest" way to tackle this particular case is look at taken_edge > in profitable_path_p. I would've prefered putting everything in your previous patch, since it wou= ld be shared between both threaders, though I suppose the forward threader is slowly dying ;-).=