[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]

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #9 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #7)
> So in this case we have
> 
> (gdb) p *path->m_vec->m_vecdata[0]
> $106 = {e = <edge 0xf4819a40 (5 -> 7)>, type = EDGE_COPY_SRC_BLOCK}
> (gdb) p *path->m_vec->m_vecdata[1]
> $107 = {e = <edge 0xf48199a0 (7 -> 9)>, type = EDGE_COPY_SRC_BLOCK}
> (gdb) p *path->m_vec->m_vecdata[2]
> $108 = {e = <edge 0xf48197e0 (9 -> 10)>, type = EDGE_NO_COPY_SRC_BLOCK}
> 
> and the last edge (9 -> 10) is known to be never executed:
> 
> <bb 9> [local count: 435262723]:
> _3 = MEM <struct vec> [(struct basic_block_def * const &)_21].m_vecdata[_2];
> _4 = iftmp.22_23 + 4294967295;
> if (_4 >= _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)!?

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 profitable,
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.

> 
> 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 would
be shared between both threaders, though I suppose the forward threader is
slowly dying ;-).