* tree-eh.c (unsplit_eh): Do not unsplit if there's already

        an edge to the new destination block.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@152310 138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index a963c93..b8c0905 100644 (file)
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2009-09-29  Richard Henderson  <rth@redhat.com>
+
+       * tree-eh.c (unsplit_eh): Do not unsplit if there's already
+       an edge to the new destination block.
+
 2009-09-29  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>
 
        PR target/41393

diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index 0f5931e..3ed92a5 100644 (file)
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -3369,6 +3369,12 @@ unsplit_eh (eh_landing_pad lp)
        return false;
     }
 
+  /* The new destination block must not already be a destination of
+     the source block, lest we merge fallthru and eh edges and get
+     all sorts of confused.  */
+  if (find_edge (e_in->src, e_out->dest))
+    return false;
+
   /* ??? I can't imagine there would be PHI nodes, since by nature
      of critical edge splitting this block should never have been
      a dominance frontier.  If cfg cleanups somehow confuse this,