adjust landing pads when changing main label

If an artificial label created for a landing pad ends up being
dropped in favor of a user-supplied label, the user-supplied label
inherits the landing pad index, but the post_landing_pad field is not
adjusted to point to the new label.

This patch fixes the problem, and adds verification that we don't
remove a label that's still used as a landing pad.

The circumstance in which this problem can be hit was unusual: removal
of a block with an unreachable label moves the label to some other
unrelated block, in case its address is taken.  In the case at hand
(pr42739.C, complicated by wrappers and cleanups), the chosen block
happened to be an EH landing pad.  (A followup patch will change that.)

for  gcc/ChangeLog

	* tree-cfg.c (cleanup_dead_labels_eh): Update
	post_landing_pad label upon change of landing pad block's
	primary label.
	(cleanup_dead_labels): Check that a removed label is not that
	of a landing pad.

diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index c73e1cb..1f0f4a2 100644 (file)
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -1481,6 +1481,7 @@ cleanup_dead_labels_eh (label_record *label_for_bb)
        if (lab != lp->post_landing_pad)
          {
            EH_LANDING_PAD_NR (lp->post_landing_pad) = 0;
+           lp->post_landing_pad = lab;
            EH_LANDING_PAD_NR (lab) = lp->index;
          }
       }
@@ -1707,7 +1708,10 @@ cleanup_dead_labels (void)
              || FORCED_LABEL (label))
            gsi_next (&i);
          else
-           gsi_remove (&i, true);
+           {
+             gcc_checking_assert (EH_LANDING_PAD_NR (label) == 0);
+             gsi_remove (&i, true);
+           }
        }
     }