[Bug tree-optimization/81192] [8 Regression] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault

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

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #5)
> There actually is some code in find_same_succ_bb to keep loop structure:
> ...
>   if (bb == NULL
>       /* Be conservative with loop structure.  It's not evident that this
> test                        
>          is sufficient.  Before tail-merge, we've just called               
> 
>          loop_optimizer_finalize, and LOOPS_MAY_HAVE_MULTIPLE_LATCHES is now
> 
>          set, so there's no guarantee that the loop->latch value is still
> valid.                      
>          But we assume that, since we've forced LOOPS_HAVE_SIMPLE_LATCHES at
> the                      
>          start of pre, we've kept that property intact throughout pre, and
> are                        
>          keeping it throughout tail-merge using this test.  */
>       || bb->loop_father->latch == bb)
>     return;
> ...
> 
> For this example, the cleanup_tree_cfg in tail_merge_optimize creates
> multiple loop latches in the inner loop, so the loop->latch value is no
> longer valid. This test needs fixing.

So here we just look at a single BB, does the above mean that we never
wanted to look for BBs the same as a loop latch?  That is, BB will always
prevail?

That said, we never want to merge blocks in a way that a former loop header
gets deleted (bb->loop_father->header == bb).  It's fine if we merge two
latches of the same loop (assuming the attached patch restricting merging
to be within the same loop is applied).

The question whether 'same' can be NULL in same_succ_flush_bb still holds
of course.

Mind taking over this PR?