Re: optimization/5477: gcc 3.0.x reserves a large stack frame, but uses only some parts of it

[Wolfgang Bangerth <bangerth@ticam.utexas.edu>]

The following reply was made to PR optimization/5477; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Klaus Espenlaub <espenlaub@informatik.uni-ulm.de>
Cc: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org>
Subject: Re: optimization/5477: gcc 3.0.x reserves a large stack frame, but
 uses only some parts of it
Date: Mon, 17 Mar 2003 17:48:32 -0600 (CST)

 > > State-Changed-From-To: open->feedback
 > > State-Changed-Why:
 > >     Klaus, for unknown reasons the attachment I find in the
 > >     report doesn't have a main() function -- thus no checking
 > >     possible. Do you still have the program so that you can
 > >     send it to me? I'll attach it to the report then.
 > [...]
 > It doesn't make much sense in this context to have a fully compilable piece of
 > code, since the problem is not that the resulting program fails to compile or
 > fails to run, but that it uses one order of magniture more stack space than it
 > would need to. 
 
 My apologies -- late night staring at PRs doesn't improve my ability to 
 think. I think it just didn't get into my head to look at assembly output.
 
 > Another comment on the base problem: the compiler bug seems to be fixed in
 > gcc-3.2.  There might still be room for improvement, but the current stack
 > consumption is quite acceptable: gcc-3.0 reserved 380 bytes of stack space,
 > while gcc-3.2 reserves only 28.
 
 For me, its either 60 bytes or 44 bytes (with -DPUTCHAR_MACRO) for 3.2.2,
 present 3.3 and mainline. Not all of these stack slots seems to be used. 
 What do you suggest we do with the report?
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/