Q: When I compile my program, the compiler crashes, but the problem
seems to go away if I compile without optimization.
Q: The compiler prints "Virtual memory exhausted" and dies while
compiling some long functions with some optimization options, such as
-funroll-loops or -fforce-addr.
A: For some programs, this can be caused by an insufficient stack.
Some source files make cc1.exe or cc1plus.exe need
preposterously large amounts of stack space, but only when you turn on
optimizations. (One user reported that an innocent-looking C source
file required 700KB of stack before cc1.exe was able to compile
it with optimizations!) Try stubediting the compiler to enlarge its
stack, as described elsewhere in this FAQ, how to enlarge the stack, before
you try any other remedies in this section.
If GCC reports that it has exhausted virtual memory, you should first
see if your DPMI memory plus the swap space is large enough (run
go32-v2 with no arguments to display the available memory) and
make more memory available, if the reported amount is too small. Some
programs really need large amounts of memory to compile and/or link.
For example, linking cc1.exe is known to consume more than 12MB
of memory. On Windows 9X, be sure to set the amount of DPMI memory
available to the DOS box to the maximum value of 65535K (64MB) in the
DOS box property sheets, under Memory, as explained in
how to enlarge memory in the DOS box.
Some users have reported that GCC seems to run out of virtual memory if TMPDIR environment variable points to a RAM disk which doesn't have enough free space. Changing TMPDIR to point to a hard disk would reportedly save the day in those cases.
Compiling with PGCC or EGCS variants of the GNU compiler, as well as GCC versions 2.95 and later (which are descendants of EGCS) can also sometimes run out of virtual memory. These versions of the compilers are memory hogs, especially when compiling C++ programs, and at high optimization levels. One particular case is when your program makes use of many STL classes. Try lowering the optimization level, or compile without optimizations.
With GCC 2.95 and later, using -pedantic or
-Wreturn-type can cause an explosion in the amount of memory
needed to compile template-heavy C++ code, such as code that uses
the STL. Since -Wall includes -Wreturn-type, it can
also cause massive memory consumption; try -Wall
-Wno-return-type to work around the problem.
One user reported that optimization switches force GCC to use a math
co-processor, which can cause it to crash on a machine that lacks a
numeric processor. Be sure you didn't delete the emu387.dxe file
from your bin subdirectory, when you compile on such machines,
and that your emulation-related setup is right. See how to set up FP emulation, for details.
GCC can sometimes crash when optimizing, especially when compiling
C++ programs, in particular if your code has some syntactic or
semantic bug. (This is usually a genuine GCC bug, not something special
to DJGPP.) Upgrade to the latest version of GCC. If that doesn't help,
then narrow the offending code fragment using the #if 0 ...
#endif paradigm. If this fragment includes an error, correct it and
try again; if it is syntactically and semantically correct, then rewrite
it as equivalent, but syntactically different one.
A GCC switch can sometimes help you zero in on the code fragment that
causes GCC to crash. If you add -Q to the GCC command line, it
will print the name of every function it compiles. The function that
makes it crash is probably the one whose name is the last one printed,
or the one after that.
As an extreme measure, don't optimize at all, if that's the only way to make your program compile.
Another reason for crashes could be some problem with your system hardware or the BIOS (like if you set an incorrect number of wait states when accessing memory, or overclock the CPU too much). To check, try running the same compilation on another machine, or review your BIOS settings and hardware configuration.
Yet another cause for such crashes can be connected with excess memory usage that GCC needs when compiling certain programs, which makes some DPMI hosts fail. For details about this, see CWSDPMI allocation problems, below.