public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Alexander Monakov <amonakov@ispras.ru>, gcc-patches@gcc.gnu.org
Cc: Alexey Nurmukhametov <nurmukhametov@ispras.ru>
Subject: Re: [RFC PATCH] tree-ssa-sink: do not sink to in front of setjmp
Date: Mon, 13 Dec 2021 15:45:43 +0100	[thread overview]
Message-ID: <4493B84A-DB6D-468B-86BF-DA5383D8CFE4@gmail.com> (raw)
In-Reply-To: <d6ba28f2-3d88-ed2c-e81-ba16e84f31ca@ispras.ru>

On December 13, 2021 3:25:47 PM GMT+01:00, Alexander Monakov <amonakov@ispras.ru> wrote:
>Greetings!
>
>While testing our patch that reimplements -Wclobbered on GIMPLE we found
>a case where tree-ssa-sink moves a statement to a basic block in front
>of a setjmp call.
>
>I am confident that this is unintended and should be considered invalid
>GIMPLE. 

Does CFG validation not catch this? That is, doesn't setjmp force the start of a new BB?

One of the edges incoming to a setjmp BB will be an edge from
>the ABNORMAL_DISPATCHER block, corresponding to transfer of control flow
>from a longjmp-like function and resulting in a "second return" from
>setjmp. When that happens, it is not possible for GIMPLE statements in
>front of setjmp to be somehow re-executed after longjmp.
>
>I am unsure how this could be prevented "once and for all" so the
>following patch just attacks one place (out of three) in
>tree-ssa-sink by checking 'bb_has_abnormal_pred (sinkbb)'. Alexey
>(Cc'ed) bootstrapped and regtested the patch on trunk.

I think sinking relies on dominance and post dominance here but post dominance may be too fragile with the abnormal cycles which are likely not backwards reachable from exit. 

That said, checking for abnormal preds is OK, I just want to make sure we detect the invalid CFG - do we? 

>The testcase is just
>
>struct __jmp_buf_tag { };
>typedef struct __jmp_buf_tag jmp_buf[1];
>struct globals { jmp_buf listingbuf; };
>extern struct globals *const ptr_to_globals;
>void foo()
>{
>  if ( _setjmp ( ((*ptr_to_globals).listingbuf )))
>    ;
>}
>
>Before tree-ssa-sink we have
>
>void foo ()
>{
>   struct globals * ptr_to_globals.0_1;
>   struct __jmp_buf_tag[1] * _2;
>
>   <bb 2> :
>   ptr_to_globals.0_1 = ptr_to_globals;
>   _2 = &ptr_to_globals.0_1->listingbuf;
>
>   <bb 3> :
>   _setjmp (_2);
>   goto <bb 5>; [INV]
>
>   <bb 4> :
>   .ABNORMAL_DISPATCHER (0);
>
>   <bb 5> :
>   return;
>
>}
>
>And tree-ssa-sink yields (see BB 3)
>
>Sinking _2 = &ptr_to_globals.0_1->listingbuf;
>  from bb 2 to bb 3
>void foo ()
>{
>   struct globals * ptr_to_globals.0_1;
>   struct __jmp_buf_tag[1] * _2;
>
>   <bb 2> :
>   ptr_to_globals.0_1 = ptr_to_globals;
>
>   <bb 3> :
>   _2 = &ptr_to_globals.0_1->listingbuf;
>   _setjmp (_2);
>   goto <bb 5>; [INV]
>
>   <bb 4> :
>   .ABNORMAL_DISPATCHER (0);
>
>   <bb 5> :
>   return;
>
>}
>
>The patch:
>
>diff --git a/gcc/tree-ssa-sink.c b/gcc/tree-ssa-sink.c
>index c5d67840be3..317e2563114 100644
>--- a/gcc/tree-ssa-sink.c
>+++ b/gcc/tree-ssa-sink.c
>@@ -461,6 +461,9 @@ statement_sink_location (gimple *stmt, basic_block frombb,
> 	  else
> 	    *togsi = gsi_after_labels (sinkbb);
> 
>+	  if (bb_has_abnormal_pred (sinkbb))
>+	    return false;
>+
> 	  return true;
> 	}
>     }

  reply	other threads:[~2021-12-13 14:45 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-13 14:25 Alexander Monakov
2021-12-13 14:45 ` Richard Biener [this message]
2021-12-13 15:20   ` Alexander Monakov
2021-12-14 11:10     ` Алексей Нурмухаметов
2022-01-03 13:41       ` Richard Biener
2022-01-03 16:35         ` Alexander Monakov
2022-01-04  7:25           ` Richard Biener
2022-01-14 18:20             ` Alexander Monakov
2022-01-14 18:20             ` [PATCH 1/3] " Alexander Monakov
2022-01-17  7:47               ` Richard Biener
2023-11-08  9:04               ` Florian Weimer
2023-11-08 10:01                 ` Richard Biener
2023-11-08 13:06                   ` Alexander Monakov
2022-01-14 18:20             ` [PATCH 2/3] tree-cfg: do not duplicate returns_twice calls Alexander Monakov
2022-01-17  8:08               ` Richard Biener
2022-07-12 20:10                 ` Alexander Monakov
2022-07-13  7:13                   ` Richard Biener
2022-07-13 14:57                     ` Alexander Monakov
2022-07-14  6:38                       ` Richard Biener
2022-07-14 20:12                         ` Alexander Monakov
2022-07-19  8:40                           ` Richard Biener
2022-07-19 20:00                             ` Alexander Monakov
2022-07-13 16:01                     ` Jeff Law
2022-01-14 18:20             ` [PATCH 3/3] tree-cfg: check placement of " Alexander Monakov
2022-01-17  8:12               ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4493B84A-DB6D-468B-86BF-DA5383D8CFE4@gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=amonakov@ispras.ru \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=nurmukhametov@ispras.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).