Re: GCC does not cope with my code

Gunnar Braun <braung@ert.rwth-aachen.de> writes:
> I'm currently developing tools that generate C++ code. The generated
> code contains a bunch of macros which are expanded by the preprocessor.
> No problem up to here. Now I'd like to compile the resulting file with
> g++, but it takes ages until I get the object file. It gets worse, if I
> try to optimize the code generation via -O (of course it gets). The
> problem is that the (source) file (after the macro expansion) isn't
> really large, it's below 700 kB. If the file gets above 700 kB, the
> compiler crashes with the famous signal 11 internal compiler error.
>
> I compiled even bigger source files with g++, so it can't be the file
> size which confuses the compiler. So I end up with the following
> question:
>
> What is wrong with the generated source file that the compiler doesn't
> cope with it?
>
> or:
>
> What changes can I apply to the _code_ to reduce compile time/make it
> possible to compile the file?


Well, most likely the problem is running out of memory -- try running the
compiler with top or vmstat running at the same time, and see if you're
running out of swap space. If so, you may be able to make things work
by increasing it, but it will still be very slow.


The thing that really causes gcc fits is really big functions, not
specifically big source files. The way gcc manages memory, it starts
allocating it when it starts compiling a function, and continues using
up more and more. When the function is complete and the code has been
emitted, it frees most of that memory and goes on to the next function.


Compounding the problem, there are a number of places where gcc can
require O(n^2) memory, so as functions get big, the memory used can go
up very fast.


About the only thing you can change to try to bring this more under
control is to try to break up the code you are generating into smaller
functions. If you do that, there's no need to split the functions
into different files, so you can use static symbols and avoid global
name space pollution.


Chris Dodd
chrisd@reservoir.com

Return to the comp.compilers page.
Search the comp.compilers archives again.