On 2 February 2011 12:28, Peter Maydell peter.maydell@linaro.org wrote:

On 2 February 2011 11:54, Peter Maydell peter.maydell@linaro.org wrote:

...

ie gcc wants (at least) 100M of RAM trying to compile a 190K sourcefile. (and probably more overall since the board has 500MB RAM total and it hit the out-of-memory condition).

On a rerun which hit the kernel OOM-killer the kernel said: Killed process 5362 (cc1) vsz:480472kB, anon-rss:469676kB, file-rss:88kB

so gcc's claim that it only wanted 100MB is underreading rather.

480MB does appear excessive; to be a little fair to gcc that file does look like it's trying to build itself as a vast inline'd set of switch statements so it will be stressing the compiler.

Is this 480MB much more than on x86 or on older versions of the compiler?

Dave (resend remembering to hit all)

On Thu, Feb 3, 2011 at 2:49 AM, Peter Maydell peter.maydell@linaro.org wrote:

On 2 February 2011 13:16, David Gilbert david.gilbert@linaro.org wrote

...

480MB does appear excessive; to be a little fair to gcc that file does look like it's trying to build itself as a vast inline'd set of switch statements so it will be stressing the compiler.

Is this 480MB much more than on x86 or on older versions of the compiler?

A quick binary-chop using ulimit on x86-32 but the same gcc "gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5" shows that on x86-32 you need about 284000K to compile this translation unit.

I haven't established exactly how much memory we need on ARM; it's more than 480MB but less than 550000K. (It takes way too long to compile the file to do a sensible binary chop.)

The resulting .o file is 1.5M on x86-32 and 1.6M on ARM (presumably partly due to debug info as we are compiling with -g -O2).

Steve's having a play with this. Providing hard files like this can compile on readily available hardware, then I'm happy.

It will be interesting to see if -fno-var-tracking r getting rid of -g helps...

-- Michael