Node:GCC optimizations, Next:, Previous:Buggy DPMI, Up:Trouble

6.4 GCC can crash during optimization

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.