From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7574 invoked by alias); 19 Jul 2011 09:01:26 -0000 Received: (qmail 7566 invoked by uid 22791); 19 Jul 2011 09:01:25 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_RG X-Spam-Check-By: sourceware.org Received: from mail-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Jul 2011 09:01:11 +0000 Received: by yxi19 with SMTP id 19so1881334yxi.20 for ; Tue, 19 Jul 2011 02:01:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.67.21 with SMTP id p21mr2716579yba.273.1311066070501; Tue, 19 Jul 2011 02:01:10 -0700 (PDT) Received: by 10.150.205.2 with HTTP; Tue, 19 Jul 2011 02:01:10 -0700 (PDT) In-Reply-To: <20110719082414.GA2687@tyan-ft48-01.lab.bos.redhat.com> References: <20110718215838.GZ2687@tyan-ft48-01.lab.bos.redhat.com> <20110719082414.GA2687@tyan-ft48-01.lab.bos.redhat.com> Date: Tue, 19 Jul 2011 10:18:00 -0000 Message-ID: Subject: Re: [PATCH] Attempt to increase RLIMIT_STACK in the driver as well as compiler (PR c++/49756, take 2) From: Richard Guenther To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg01487.txt.bz2 On Tue, Jul 19, 2011 at 10:24 AM, Jakub Jelinek wrote: > On Mon, Jul 18, 2011 at 11:58:38PM +0200, Jakub Jelinek wrote: >> Especially the FEs and gimplification are highly recursive on more compl= ex >> (especially badly generated) testcases, the following patch attempts to >> increase stack size to 64MB if possible. =A0It 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). > > Here is a slightly modified variant which will avoid the setrlimit syscall > if it wouldn't change anything (which is either if the soft limit is alre= ady >>=3D 64MB or the hard limit is not infinity and equal to the soft limit). > At least in toplev_main it is very likely the setrlimit will not be needed > if it has been done in the driver already. Looks like sth for libiberty to avoid replicating it two times? Richard. > 2011-07-19 =A0Jakub Jelinek =A0 > > =A0 =A0 =A0 =A0PR c++/49756 > =A0 =A0 =A0 =A0* gcc.c (main): Try to increase RLIMIT_STACK to at least > =A0 =A0 =A0 =A064MB if possible. > =A0 =A0 =A0 =A0* toplev.c (toplev_main): Likewise. > > --- gcc/gcc.c.jj =A0 =A0 =A0 =A02011-07-08 15:09:38.000000000 +0200 > +++ gcc/gcc.c =A0 2011-07-19 10:15:25.000000000 +0200 > @@ -6156,6 +6156,24 @@ main (int argc, char **argv) > =A0 signal (SIGCHLD, SIG_DFL); > =A0#endif > > +#if defined(HAVE_SETRLIMIT) && defined(RLIMIT_STACK) && defined(RLIM_INF= INITY) > + =A0{ > + =A0 =A0/* Parsing and gimplification sometimes need quite large stack. > + =A0 =A0 =A0 Increase stack size limits if possible. =A0*/ > + =A0 =A0struct rlimit rlim; > + =A0 =A0if (getrlimit (RLIMIT_STACK, &rlim) =3D=3D 0 > + =A0 =A0 =A0 && rlim.rlim_cur !=3D RLIM_INFINITY > + =A0 =A0 =A0 && rlim.rlim_cur < 64 * 1024 * 1024 > + =A0 =A0 =A0 && (rlim.rlim_max =3D=3D RLIM_INFINITY || rlim.rlim_cur < r= lim.rlim_max)) > + =A0 =A0 =A0{ > + =A0 =A0 =A0 rlim.rlim_cur =3D 64 * 1024 * 1024; > + =A0 =A0 =A0 if (rlim.rlim_max !=3D RLIM_INFINITY) > + =A0 =A0 =A0 =A0 rlim.rlim_cur =3D MIN (rlim.rlim_cur, rlim.rlim_max); > + =A0 =A0 =A0 setrlimit (RLIMIT_STACK, &rlim); > + =A0 =A0 =A0} > + =A0} > +#endif > + > =A0 /* Allocate the argument vector. =A0*/ > =A0 alloc_args (); > > --- gcc/toplev.c.jj =A0 =A0 2011-07-11 10:39:50.000000000 +0200 > +++ gcc/toplev.c =A0 =A0 =A0 =A02011-07-19 10:15:37.000000000 +0200 > @@ -1911,6 +1911,24 @@ do_compile (void) > =A0int > =A0toplev_main (int argc, char **argv) > =A0{ > +#if defined(HAVE_SETRLIMIT) && defined(RLIMIT_STACK) && defined(RLIM_INF= INITY) > + =A0{ > + =A0 =A0/* Parsing and gimplification sometimes need quite large stack. > + =A0 =A0 =A0 Increase stack size limits if possible. =A0*/ > + =A0 =A0struct rlimit rlim; > + =A0 =A0if (getrlimit (RLIMIT_STACK, &rlim) =3D=3D 0 > + =A0 =A0 =A0 && rlim.rlim_cur !=3D RLIM_INFINITY > + =A0 =A0 =A0 && rlim.rlim_cur < 64 * 1024 * 1024 > + =A0 =A0 =A0 && (rlim.rlim_max =3D=3D RLIM_INFINITY || rlim.rlim_cur < r= lim.rlim_max)) > + =A0 =A0 =A0{ > + =A0 =A0 =A0 rlim.rlim_cur =3D 64 * 1024 * 1024; > + =A0 =A0 =A0 if (rlim.rlim_max !=3D RLIM_INFINITY) > + =A0 =A0 =A0 =A0 rlim.rlim_cur =3D MIN (rlim.rlim_cur, rlim.rlim_max); > + =A0 =A0 =A0 setrlimit (RLIMIT_STACK, &rlim); > + =A0 =A0 =A0} > + =A0} > +#endif > + > =A0 expandargv (&argc, &argv); > > =A0 /* Initialization of GCC's environment, and diagnostics. =A0*/ > > =A0 =A0 =A0 =A0Jakub >