Re: middle-end/3973: GCC fails to bootstrap with 80+160MB memory / optimization

Re: middle-end/3973: GCC fails to bootstrap with 80+160MB memory / optimization

[Gerald Pfeifer]

The following reply was made to PR middle-end/3973; it has been noted by GNATS.

From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: middle-end/3973: GCC fails to bootstrap with 80+160MB memory /
 optimization
Date: Fri, 27 Dec 2002 20:53:41 +0100 (CET)

 On Wed, 11 Dec 2002 bangerth@dealii.org wrote:
 >     Gerald, I hate to step on your toes, but I guess there is
 >     not much that can be done about this report -- newer gccs
 >     do more optimization, and they need more memory and compile
 >     time. Do you agree that there are probably better testcases
 >     for this kind of problem in the database?
 
 Well.  This testcase would have been "self contained" (in that GCC
 itself is the testcase) and it *is* a clear regression, but given the
 current trend, what can we realistically do about it?
 
 (I find it a bit disturbing that several old PRs of mine which
 describe clear performance regressions are getting closed these
 days without any form of resolution, but let's assume there are
 other, better(?) PRs for this problem in our database.)
 
 Gerald

Re: middle-end/3973: GCC fails to bootstrap with 80+160MB memory / optimization

[Wolfgang Bangerth]

The following reply was made to PR middle-end/3973; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
Cc: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/3973: GCC fails to bootstrap with 80+160MB memory /
 optimization
Date: Mon, 6 Jan 2003 18:06:34 -0600 (CST)

 > > I would not even pretend I would disagree with you on the matter of
 > > compile time and memory consumption, but every time I brought this up
 > > (even with numbers from our own project), nothing really happens.
 > 
 > Have you created high-priority PRs for such projects? That might be
 > better than this PR...
 
 The project is 200k lines of template heavy C++. Not exactly a smaller 
 testcase. I occasionally filed reports for cases where compile time 
 exploded (and these were fixed mostly), but the general trend of 3.3 being 
 (more than) twice as slow as 2.95 for example is unchecked, and I don't 
 have a simple testcase for that, unfortunately.
 
 In fact, there are testcases already around: the automatic SPEC testers 
 also log daily compile times for fixed programs. Every once in a while 
 someone notices that something gets slower and sometimes even can point to 
 a particular patch, but the general trend is not broken by that.
 
 
 > > So what should we do?
 > 
 > ...which I agree to close.
 
 I'll do it, but only with a certain amount of reluctance :-(
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

Re: middle-end/3973: GCC fails to bootstrap with 80+160MB memory / optimization

[bangerth]

Synopsis: GCC fails to bootstrap with 80+160MB memory / optimization

State-Changed-From-To: feedback->closed
State-Changed-By: bangerth
State-Changed-When: Mon Jan  6 16:06:58 2003
State-Changed-Why:
    Based on the discussion and Gerald's ok.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3973

Re: middle-end/3973: GCC fails to bootstrap with 80+160MB memory / optimization

[Gerald Pfeifer]

The following reply was made to PR middle-end/3973; it has been noted by GNATS.

From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: middle-end/3973: GCC fails to bootstrap with 80+160MB memory /
 optimization
Date: Tue, 7 Jan 2003 00:45:15 +0100 (CET)

 On Mon, 6 Jan 2003, Wolfgang Bangerth wrote:
 > I would not even pretend I would disagree with you on the matter of
 > compile time and memory consumption, but every time I brought this up
 > (even with numbers from our own project), nothing really happens.
 
 Have you created high-priority PRs for such projects? That might be
 better than this PR...
 
 > So what should we do?
 
 ...which I agree to close.
 
 Gerald

Re: middle-end/3973: GCC fails to bootstrap with 80+160MB memory / optimization

[Wolfgang Bangerth]

The following reply was made to PR middle-end/3973; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
Cc: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org>
Subject: Re: middle-end/3973: GCC fails to bootstrap with 80+160MB memory /
 optimization
Date: Mon, 6 Jan 2003 16:36:41 -0600 (CST)

 On Fri, 27 Dec 2002, Gerald Pfeifer wrote:
 
 > On Wed, 11 Dec 2002 bangerth@dealii.org wrote:
 > >     Gerald, I hate to step on your toes, but I guess there is
 > >     not much that can be done about this report -- newer gccs
 > >     do more optimization, and they need more memory and compile
 > >     time. Do you agree that there are probably better testcases
 > >     for this kind of problem in the database?
 > 
 > Well.  This testcase would have been "self contained" (in that GCC
 > itself is the testcase) and it *is* a clear regression,
 
 Only true, but it's not exactly obvious where exactly the problem is. It's 
 not in the form of a single preprocessed file that would make it so much 
 easier to debug the problem.
 
 > but given the current trend, what can we realistically do about it?
 > 
 > (I find it a bit disturbing that several old PRs of mine which
 > describe clear performance regressions are getting closed these
 > days without any form of resolution, but let's assume there are
 > other, better(?) PRs for this problem in our database.)
 
 I would not even pretend I would disagree with you on the matter of
 compile time and memory consumption, but every time I brought this up 
 (even with numbers from our own project), nothing really happens. I fear 
 that if we leave such general reports open, they will be open forever as 
 nobody ventures to look at them. I personally am happy to leave it open, 
 but since I know nothing about gcc's internals, I also can't help in 
 fixing it :-(
 
 So what should we do?
 
 Regards
   Wolfgang
 
 PS: Which are those other reports you mention?
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

Re: middle-end/3973: GCC fails to bootstrap with 80+160MB memory / optimization

[bangerth]

Synopsis: GCC fails to bootstrap with 80+160MB memory / optimization

State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Tue Dec 10 16:19:45 2002
State-Changed-Why:
    Gerald, I hate to step on your toes, but I guess there is
    not much that can be done about this report -- newer gccs
    do more optimization, and they need more memory and compile
    time. Do you agree that there are probably better testcases
    for this kind of problem in the database?
    
    Cheers
      Wolfgang

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3973

middle-end/3973: GCC fails to bootstrap with 80+160MB memory / optimization

[pfeifer]

>Number:         3973
>Category:       middle-end
>Synopsis:       GCC fails to bootstrap with 80+160MB memory / optimization
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 09 07:16:02 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        3.1 20010808 (experimental)
>Organization:
>Environment:
System: SunOS hostname 5.6 Generic_105181-28 sun4m sparc sun4m
Architecture: sun4

host: sparc-sun-solaris2.6
build: sparc-sun-solaris2.6
target: sparc-sun-solaris2.6
configured with: /sw/test/gcc/cvs/configure --prefix=/sw/test/gcc/SunOS --enable-languages=c,c++,objc,java
>Description:
Bootstrap on a sparc-sun-solaris2.6 box with 80MB of main memory
plus 160MB of swap fails with "out of memory":

stage2/xgcc -Bstage2/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.6/bin/ -c
-DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes   -DHAVE_CONFIG_H    -I. -Ijava -I/sw/test/gcc/cvs/gcc
-I/sw/test/gcc/cvs/gcc/java -I/sw/test/gcc/cvs/gcc/config
-I/sw/test/gcc/cvs/gcc/../include /sw/test/gcc/cvs/gcc/java/parse.c
-o java/parse.o
cc1: Cannot allocate 8744016 bytes after allocating 27115520 bytes
gmake[2]: *** [java/parse.o] Error 1
gmake[2]: Leaving directory `/tmp/OBJ-0808-0716/gcc'
gmake[1]: *** [stage3_build] Error 2
gmake[1]: Leaving directory `/tmp/OBJ-0808-0716/gcc'
gmake: *** [bootstrap-lean] Error 2

This is a regression from GCC 2.95.x and even GCC 3.0. Probably memory
leaks and inefficient/too expensive optimizations.

>How-To-Repeat:
	mkdir objdir ; cd objdir
	$GCC_SOURCE/configure --enable-languages=c,c++,objc,java
	make bootstrap
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted: