public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] tree-optimization/108691 - remove trigger-happy assert
@ 2023-02-21 12:47 Richard Biener
  2023-02-21 12:53 ` Jakub Jelinek
  0 siblings, 1 reply; 2+ messages in thread
From: Richard Biener @ 2023-02-21 12:47 UTC (permalink / raw)
  To: gcc-patches; +Cc: Jakub Jelinek

The following gets rid of the idea that we should prevent setjmp
like calls from popping up in uncontrolled way in the IL for now.
The solution is probably to handle it similar as noreturn has
the ctrl-altering flag on stmts, but use another flag, for example
ctrl-receiving which would also make sure the stmt is first.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

OK?

	PR tree-optimization/108691
	* tree-ssa-dce.cc (eliminate_unnecessary_stmts): Remove
	assert about calls_setjmp not becoming true when it was false.

	* gcc.dg/pr108691.c: New testcase.
---
 gcc/testsuite/gcc.dg/pr108691.c | 9 +++++++++
 gcc/tree-ssa-dce.cc             | 8 +++++---
 2 files changed, 14 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr108691.c

diff --git a/gcc/testsuite/gcc.dg/pr108691.c b/gcc/testsuite/gcc.dg/pr108691.c
new file mode 100644
index 00000000000..e412df10f22
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr108691.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+extern int __attribute__((returns_twice)) setjmp(void*);
+
+void bbb(void) {
+  int (*fnptr)(void*) = setjmp;
+  fnptr(0);
+}
diff --git a/gcc/tree-ssa-dce.cc b/gcc/tree-ssa-dce.cc
index ceeb0ad5ab3..0ae998f86f9 100644
--- a/gcc/tree-ssa-dce.cc
+++ b/gcc/tree-ssa-dce.cc
@@ -1512,10 +1512,12 @@ eliminate_unnecessary_stmts (bool aggressive)
 	remove_edge (to_remove_edges[i]);
       cfg_altered = true;
     }
-  /* When we cleared calls_setjmp we can purge all abnormal edges.  Do so.  */
-  if (cfun->calls_setjmp != had_setjmp)
+  /* When we cleared calls_setjmp we can purge all abnormal edges.  Do so.
+     ???  We'd like to assert that setjmp calls do not pop out of nothing
+     but we currently lack a per-stmt way of noting whether a call was
+     recognized as returns-twice (or rather receives-control).  */
+  if (!cfun->calls_setjmp && had_setjmp)
     {
-      gcc_assert (!cfun->calls_setjmp);
       /* Make sure we only remove the edges, not dominated blocks.  Using
 	 gimple_purge_dead_abnormal_call_edges would do that and we
 	 cannot free dominators yet.  */
-- 
2.35.3

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

* Re: [PATCH] tree-optimization/108691 - remove trigger-happy assert
  2023-02-21 12:47 [PATCH] tree-optimization/108691 - remove trigger-happy assert Richard Biener
@ 2023-02-21 12:53 ` Jakub Jelinek
  0 siblings, 0 replies; 2+ messages in thread
From: Jakub Jelinek @ 2023-02-21 12:53 UTC (permalink / raw)
  To: Richard Biener; +Cc: gcc-patches

On Tue, Feb 21, 2023 at 01:47:59PM +0100, Richard Biener wrote:
> The following gets rid of the idea that we should prevent setjmp
> like calls from popping up in uncontrolled way in the IL for now.
> The solution is probably to handle it similar as noreturn has
> the ctrl-altering flag on stmts, but use another flag, for example
> ctrl-receiving which would also make sure the stmt is first.

Yes, I'm all for it.
> 
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> 
> OK?
> 
> 	PR tree-optimization/108691
> 	* tree-ssa-dce.cc (eliminate_unnecessary_stmts): Remove
> 	assert about calls_setjmp not becoming true when it was false.
> 
> 	* gcc.dg/pr108691.c: New testcase.

Ok.

	Jakub


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

end of thread, other threads:[~2023-02-21 12:53 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-21 12:47 [PATCH] tree-optimization/108691 - remove trigger-happy assert Richard Biener
2023-02-21 12:53 ` Jakub Jelinek

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