https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98950
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the issue seems we have a recorded path of length 1 which isn't handled but
also not rejected in the generic thread_through_all_blocks machinery which
makes it not deleted by the actual threading.
Freeing of paths is a bit awkward scattered through the code rather than
being done when releasing the vector of paths.
$12 = {e = <edge 0x7ffff6970150 (30 -> 24)>, type = EDGE_NO_COPY_SRC_BLOCK}
is the path we end up with. The path is originally registered with length
two but adjusted via
#0 vec<jump_thread_edge*, va_heap, vl_embed>::block_remove (
this=0x3a6b900 = {...}, ix=0, len=1)
at /home/rguenther/src/gcc2/gcc/vec.h:1136
#1 0x00000000018235fb in vec<jump_thread_edge*, va_heap, vl_ptr>::block_remove
(Python Exception <class 'gdb.error'> There is no member or method named
m_vecpfx.:
this=0x3a6cea0, ix=0, len=1) at /home/rguenther/src/gcc2/gcc/vec.h:2029
#2 0x000000000181f68e in adjust_paths_after_duplication (curr_path_num=0)
at /home/rguenther/src/gcc2/gcc/tree-ssa-threadupdate.c:2292
#3 0x000000000181fe27 in duplicate_thread_path (
entry=<edge 0x7ffff6970ae0 (7 -> 30)>,
exit=<edge 0x7ffff69702d0 (19 -> 20)>, region=0x3ace140, n_region=2,
current_path_no=0)
at /home/rguenther/src/gcc2/gcc/tree-ssa-threadupdate.c:2462
#4 0x0000000001820243 in thread_through_all_blocks (
may_peel_loop_headers=true)
at /home/rguenther/src/gcc2/gcc/tree-ssa-threadupdate.c:2594
to this degenerate state.
I'm lost as to how this all should work. The releasing of paths all around
the transform code rather than simply at the end of thread_through_all_blocks
where we do
paths.release ();
(but appearantly rely on it being empty) makes things awkward to fix for me.
Jeff?
