Re: latent bug in unreachable code removal?

[Jan Hubicka <jh at suse dot cz>]

> On Tue, Jul 17, 2001 at 06:11:53PM +0200, Jan Hubicka wrote:
> > I get the basic block 0 overing by the CALL_INSN to y.0
> > Then basic block 2 contains label "xlab":
> > ;; Start of basic block 2, registers live: (nil)
> > (code_label/s 34 33 63 2 ("xlab") "" [1 uses])
> > 
> > but the edge is:
> > Successors:  1 (fallthru) 3 (ab,abcall)
> > 
> > to:
> > ;; Start of basic block 3, registers live: (nil)
> > (code_label/s 46 41 65 10 "" "" [2 uses])
> > 
> > That looks like completely bogus destination.
> 
> No, there is some compensation and cleanup code that
> happens before we branch to the actual user label.
Hmm, complex problems always have simple answer.

the problem is in redirect_edge, that got edge from abnormal call
and called redirect_jump on it.  Redirection of jump has suceeded
so the real receiver label got failed.

I am going to install this as obvious, once regtesting complettes.

Honza

Tue Jul 17 18:48:08 CEST 2001  Jan Hubicka  <jh@suse.cz>

	* flow.c (redirect_edge_and_branch): Bail out on the complex edges.

Index: flow.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/flow.c,v
retrieving revision 1.429
diff -c -3 -p -r1.429 flow.c
*** flow.c	2001/07/17 04:55:23	1.429
--- flow.c	2001/07/17 16:47:03
*************** redirect_edge_and_branch (e, target)
*** 1777,1782 ****
--- 1777,1785 ----
    basic_block src = e->src;
    rtx insn = src->end;
  
+   if (e->flags & EDGE_COMPLEX)
+     return false;
+ 
    if (try_redirect_by_replacing_jump (e, target))
      return true;
    /* Do this fast path late, as we want above code to simplify for cases