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 074903858C52; Mon,  1 Aug 2022 12:58:39 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 074903858C52
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.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 12:58:39 +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: rguenth 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: cc
Message-ID: <bug-106495-4-XLKgVlXcwf@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106495-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106495-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, 01 Aug 2022 12:58:40 -0000

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
So in this case we have

(gdb) p *path->m_vec->m_vecdata[0]
$106 =3D {e =3D <edge 0xf4819a40 (5 -> 7)>, type =3D EDGE_COPY_SRC_BLOCK}
(gdb) p *path->m_vec->m_vecdata[1]
$107 =3D {e =3D <edge 0xf48199a0 (7 -> 9)>, type =3D EDGE_COPY_SRC_BLOCK}
(gdb) p *path->m_vec->m_vecdata[2]
$108 =3D {e =3D <edge 0xf48197e0 (9 -> 10)>, type =3D EDGE_NO_COPY_SRC_BLOC=
K}

and the last edge (9 -> 10) is known to be never executed:

<bb 9> [local count: 435262723]:
_3 =3D MEM <struct vec> [(struct basic_block_def * const &)_21].m_vecdata[_=
2];
_4 =3D iftmp.22_23 + 4294967295;
if (_4 >=3D _20)
  goto <bb 10>; [0.00%]

we've isolated a quite "unlikely" combo here.  We could go for generalizing
the earlier patch, disqualifying the path if any of the edges involved.

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)!?

So the "cheapest" way to tackle this particular case is look at taken_edge
in profitable_path_p.=