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-da...@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.guerr...@gmx.de>
...
