This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: optimization/5477: gcc 3.0.x reserves a large stack frame, butuses only some parts of it
- From: Wolfgang Bangerth <bangerth at ticam dot utexas dot edu>
- To: Klaus Espenlaub <espenlaub at informatik dot uni-ulm dot de>
- Cc: gcc-bugs at gcc dot gnu dot org, <gcc-gnats at gcc dot gnu dot org>
- Date: Mon, 17 Mar 2003 17:48:32 -0600 (CST)
- Subject: Re: optimization/5477: gcc 3.0.x reserves a large stack frame, butuses only some parts of it
> > 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 at ticam dot utexas dot edu
www: http://www.ticam.utexas.edu/~bangerth/