This is a compiler bug that occurs on Debian squeeze.. uname -a Linux caraway 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686 GNU/Linux gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.5 (Debian 4.4.5-8) g++ -save-temps -c -o gcc-bug.o gcc-bug.cc g++: Internal error: Killed (program cc1plus) Please submit a full bug report. See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions.
gcc4.4.x is not maintained anymore. Please try again with a GCC from a currently maintained branch and in case file a proper report: http://gcc.gnu.org/bugs/#report
Also this "ICE" is really the kernel killing the program as it ran out of memory or it was over one of the ulimits. Most likely ran of memory.
Indeed.
Why is GCC comsuming so much memory? The program has 6.4MB source code, it is a single function. All optimizations are turned off. And there is 2GB memory in the system. Well, shouldn't it be possible to compile this program?
6.4MB in a single function is the problem. The compiler has to process that entire function at once. And 2GB is not a great amount.
(In reply to comment #4) > Why is GCC comsuming so much memory? > > The program has 6.4MB source code, it is a single function. All optimizations > are turned off. And there is 2GB memory in the system. > > Well, shouldn't it be possible to compile this program? That depends on the program, where the memory goes, possible bugs, etc. To start investigating this, GCC devs would need the info requested here: http://gcc.gnu.org/bugs/#report That said, even if you provided that info, it is unlikely that anyone will look into this bug, since it is a unusual case. If adding 2 or 4 more GBs of memory (or splitting the function into many small pieces) solves the issue, then it is simpler to just do that, and focus on fixing other bugs. Of course, nothing prevents you from investigating the issue yourself. Perhaps you are able to uncover a clear bug, memory leak or potential improvement. See: http://gcc.gnu.org/wiki/Speedup_areas http://gcc.gnu.org/wiki/Memory_management http://gcc.gnu.org/wiki/PerformanceTesting