public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* adjust landing pads when changing main label
@ 2021-07-13  3:09 Alexandre Oliva
  2021-07-13  7:46 ` Richard Biener
  0 siblings, 1 reply; 2+ messages in thread
From: Alexandre Oliva @ 2021-07-13  3:09 UTC (permalink / raw)
  To: gcc-patches


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.)

Regstrapped on x86_64-linux-gnu.  Ok to install?


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.
---
 gcc/tree-cfg.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index c73e1cbdda6b9..1f0f4a2c6eb2c 100644
--- 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);
+	    }
 	}
     }
 

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: adjust landing pads when changing main label
  2021-07-13  3:09 adjust landing pads when changing main label Alexandre Oliva
@ 2021-07-13  7:46 ` Richard Biener
  0 siblings, 0 replies; 2+ messages in thread
From: Richard Biener @ 2021-07-13  7:46 UTC (permalink / raw)
  To: Alexandre Oliva; +Cc: GCC Patches

On Tue, Jul 13, 2021 at 5:10 AM Alexandre Oliva <oliva@adacore.com> wrote:
>
>
> 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.)
>
> Regstrapped on x86_64-linux-gnu.  Ok to install?

OK.

>
> 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.
> ---
>  gcc/tree-cfg.c |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
> index c73e1cbdda6b9..1f0f4a2c6eb2c 100644
> --- 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);
> +           }
>         }
>      }
>
>
> --
> Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
>    Free Software Activist                       GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about <https://stallmansupport.org>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-07-13  7:47 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-13  3:09 adjust landing pads when changing main label Alexandre Oliva
2021-07-13  7:46 ` Richard Biener

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).