Attempt to increase RLIMIT_STACK in the driver as well as compiler (PR c++/49756)

Submitted by Jakub Jelinek on July 18, 2011, 9:58 p.m.

Details

Message ID 20110718215838.GZ2687@tyan-ft48-01.lab.bos.redhat.com
State New
Headers show

Commit Message

Jakub Jelinek July 18, 2011, 9:58 p.m.
Hi!

Especially the FEs and gimplification are highly recursive on more complex
(especially badly generated) testcases, the following patch attempts to
increase stack size to 64MB if possible.  It is done in the driver
(where it can affect the children of the driver early) and also in
toplev_main to make similar results when invoking the compiler by hand,
unless mmap of some shared library or some other mmap make it impossible
to have such a large stack.

Bootstrapped/regtested on x86_64-linux and i686-linux, cures
gcc.c-torture/compile/limits-exprparen.c ICEs on x86_64-linux on all
-O* levels as well as the testcase from this PR (which is quite large and
compile time consuming, so not including it in this testcase).

2011-07-18  Jakub Jelinek  <jakub@redhat.com>

	PR c++/49756
	* gcc.c (main): Try to increase RLIMIT_STACK to at least
	64MB if possible.
	* toplev.c (toplev_main): Likewise.


	Jakub

Comments

Mike Stump July 19, 2011, 7:56 a.m.
On Jul 18, 2011, at 2:58 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> Especially the FEs and gimplification are highly recursive on more complex
> (especially badly generated) testcases, the following patch attempts to
> increase stack size to 64MB if possible.

No, you'd need a max in there or a condition to ensure the new code doesn't lower the limit for this to be true?
Mike Stump July 19, 2011, 7:59 a.m.
On Jul 19, 2011, at 12:56 AM, Mike Stump <mikestump@comcast.net> wrote:

> On Jul 18, 2011, at 2:58 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> Especially the FEs and gimplification are highly recursive on more complex
>> (especially badly generated) testcases, the following patch attempts to
>> increase stack size to 64MB if possible.
> 
> No, you'd need a max in there or a condition to ensure the new code doesn't lower the limit for this to be true?

Ah, never mind I missed one little part of the patch.

Patch hide | download patch | download mbox

--- gcc/gcc.c.jj	2011-07-08 15:09:38.000000000 +0200
+++ gcc/gcc.c	2011-07-18 21:13:18.000000000 +0200
@@ -6156,6 +6156,22 @@  main (int argc, char **argv)
   signal (SIGCHLD, SIG_DFL);
 #endif
 
+#if defined(HAVE_SETRLIMIT) && defined(RLIMIT_STACK) && defined(RLIM_INFINITY)
+  {
+    /* Parsing and gimplification sometimes need quite large stack.
+       Increase stack size limits if possible.  */
+    struct rlimit rlim;
+    if (getrlimit (RLIMIT_STACK, &rlim) == 0
+	&& rlim.rlim_cur != RLIM_INFINITY)
+      {
+	rlim.rlim_cur = MAX (rlim.rlim_cur, 64 * 1024 * 1024);
+	if (rlim.rlim_max != RLIM_INFINITY)
+	  rlim.rlim_cur = MIN (rlim.rlim_cur, rlim.rlim_max);
+	setrlimit (RLIMIT_STACK, &rlim);
+      }
+  }
+#endif
+
   /* Allocate the argument vector.  */
   alloc_args ();
 
--- gcc/toplev.c.jj	2011-07-11 10:39:50.000000000 +0200
+++ gcc/toplev.c	2011-07-18 21:14:24.000000000 +0200
@@ -1911,6 +1911,22 @@  do_compile (void)
 int
 toplev_main (int argc, char **argv)
 {
+#if defined(HAVE_SETRLIMIT) && defined(RLIMIT_STACK) && defined(RLIM_INFINITY)
+  {
+    /* Parsing and gimplification sometimes need quite large stack.
+       Increase stack size limits if possible.  */
+    struct rlimit rlim;
+    if (getrlimit (RLIMIT_STACK, &rlim) == 0
+	&& rlim.rlim_cur != RLIM_INFINITY)
+      {
+	rlim.rlim_cur = MAX (rlim.rlim_cur, 64 * 1024 * 1024);
+	if (rlim.rlim_max != RLIM_INFINITY)
+	  rlim.rlim_cur = MIN (rlim.rlim_cur, rlim.rlim_max);
+	setrlimit (RLIMIT_STACK, &rlim);
+      }
+  }
+#endif
+
   expandargv (&argc, &argv);
 
   /* Initialization of GCC's environment, and diagnostics.  */