public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] Fixup current_pass after running IPA transforms
@ 2011-06-27 14:47 Richard Guenther
  2011-06-27 15:37 ` Jan Hubicka
  0 siblings, 1 reply; 2+ messages in thread
From: Richard Guenther @ 2011-06-27 14:47 UTC (permalink / raw)
  To: gcc-patches; +Cc: Jan Hubicka


Running IPA transforms will mess up current_pass (and reset it
to NULL), ICEing later for IPA PTA.  I also don't see any
code that would avoid doing IPA transforms twice in case
we put another small IPA pass in the late IPA pass queue.  Honza,
I guess we need to add some PROP_ipa_transforms_applied and
simply make the late IPA passes depend on that?

Noticed when adding a testcase for the now working PR49394

Anyway, bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

2011-06-27  Richard Guenther  <rguenther@suse.de>

	PR tree-optimization/49394
	* passes.c (execute_one_pass): Restore current_pass after
	applying IPA transforms.

	* g++.dg/torture/pr49394.C: New testcase.

Index: gcc/passes.c
===================================================================
--- gcc/passes.c	(revision 175526)
+++ gcc/passes.c	(working copy)
@@ -2030,6 +2030,8 @@ execute_one_pass (struct opt_pass *pass)
       do_per_function (apply_ipa_transforms, (void *)&applied);
       if (applied)
         cgraph_remove_unreachable_nodes (true, dump_file);
+      /* Restore current_pass.  */
+      current_pass = pass;
     }
 
   if (!quiet_flag && !cfun)
Index: gcc/testsuite/g++.dg/torture/pr49394.C
===================================================================
--- gcc/testsuite/g++.dg/torture/pr49394.C	(revision 0)
+++ gcc/testsuite/g++.dg/torture/pr49394.C	(revision 0)
@@ -0,0 +1,50 @@
+// { dg-do run }
+// { dg-options "-fipa-pta -fnon-call-exceptions" }
+
+struct Mutex
+{
+  bool locked;
+  ~Mutex ()
+  {
+    if (locked)
+      throw 0;
+  }
+  void lock ()
+  {
+    locked = true;
+  }
+  void unlock ()
+  {
+    if (!locked)
+      throw 0;
+    locked = false;
+  }
+};
+
+struct lock_guard
+{
+  Mutex *m;
+  lock_guard (Mutex *m) : m(m)
+  {
+  }
+  ~lock_guard ()
+  {
+    m->unlock ();
+  }
+};
+
+int
+main ()
+{
+  Mutex m;
+  m.lock ();
+  try
+  {
+    lock_guard l (&m);
+  }
+  catch ( ...)
+  {
+    __builtin_abort ();
+  }
+  return 0;
+}

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

* Re: [PATCH] Fixup current_pass after running IPA transforms
  2011-06-27 14:47 [PATCH] Fixup current_pass after running IPA transforms Richard Guenther
@ 2011-06-27 15:37 ` Jan Hubicka
  0 siblings, 0 replies; 2+ messages in thread
From: Jan Hubicka @ 2011-06-27 15:37 UTC (permalink / raw)
  To: Richard Guenther; +Cc: gcc-patches, Jan Hubicka

> 
> Running IPA transforms will mess up current_pass (and reset it
> to NULL), ICEing later for IPA PTA.  I also don't see any
> code that would avoid doing IPA transforms twice in case
> we put another small IPA pass in the late IPA pass queue.  Honza,
> I guess we need to add some PROP_ipa_transforms_applied and
> simply make the late IPA passes depend on that?

Well, the transforms are added into cgraph node at a time IPA pass is run and
then when non-IPA pass is run the transform is applied and removed from the
list.

The passmanager was originally intended to allow arbitrary ping-pong in between
ipa/small-ipa and local passes doing the right thing (i.e. applying the ipa
passes run since last non-IPA pass first time non-IPA pass is executed after a
sequence of IPA passes.

So the transforms are not run twice with IPA-PTA even if apply_ipa_transforms is.

Honza

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

end of thread, other threads:[~2011-06-27 15:16 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-27 14:47 [PATCH] Fixup current_pass after running IPA transforms Richard Guenther
2011-06-27 15:37 ` Jan Hubicka

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