This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
FW: gcc uses too much stack?
- From: Jay K <jay dot krell at cornell dot edu>
- To: gcc <gcc at gcc dot gnu dot org>, <juan dot guerrero at gmx dot de>
- Date: Sun, 8 Jan 2012 05:47:11 +0000
- Subject: FW: gcc uses too much stack?
- References: <201201080505.q08551Jm006191@delorie.com>,<COL101-W49C91D0F5FF9A94C259F48E69B0@phx.gbl>
Have people considered that stack space should be used more conservatively by gcc?
More malloc, less alloca, fewer/smaller local variables?
More std::stack or such, less recursion on the machine stack?
(Yes, I know std::stack has no existing use in gcc yet.)
Don't make the amount of stack used dependent on the input?
If something can be compiled with N stack, then anything can be?
? Is a reasonable goal?
You know, heap is generally much larger than stack, and easier to detect exhaustion of?
Granted, yes, I understand very well, heap is much slower to allocate and requires explicit free,
and is subject to fragmentation.
Thanks,
?- Jay
> Date: Sun, 8 Jan 2012 00:05:01 -0500
> To: djgpp-digest-daily@delorie.com
>
> 2012/01/07/15:03:06 ANNOUNCE: DJGPP port of GNU binutils 2.22 uploaded.
>
> ----------------------------------------------------------------------
>
...
> DJGPP specific changes.
> =======================
> - This port allows a maximal number of 4294967296 relocations per object file
> and a maximal number of 4294967296 of lines per executable file.
> The previous limits were the classical COFF limitations of 65536 for boths.
> Please note, that due to limitations inherent to DOS and memory ressources
> not every file can be compiled. E.g.: to be able to compile a single file
> containing up to 3 * 65536 relocations I had to increment stack space of
> cc1.exe from 2MB to 10MB. If the file contains 4 * 65536 relocations then
> cc1.exe aborts because memory has become exhausted. Neither as.exe nor
> ld.exe have shown memory issues. Both have the standard stack space of
> 512KB. In other words, even if 32 bit values for relocation and line
> counters are now supported by DJGPP port of as.exe and ld.exe it does not
> imply that large files can be successfully compiled and linked. There are
> memory limitations that may not be solvable.
...
>
> Enjoy.
>
> Guerrero, Juan Manuel <juan.guerrero@gmx.de>
...