http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #11 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 13:16:03 UTC --- Thanks for the responses - I will try again with '--enable-checking=release'. But, I still don't think this bug is a "non-issue" - here's why: RE: wbrana 2012-08-05 12:27:52 UTC > 2 GB RAM isn't enough. > It isn't good idea to use x86_64 with 2 GB RAM. Sorry, but gcc shouldn't be enforcing this on us - I thought it was supposed to be capable of being an embedded systems compiler - are you saying gcc cannot be compiled or run on any embedded system with less than 2GB RAM ? Surely not! RE: [reply] [-] Comment 9 Steven Bosscher 2012-08-05 12:33:56 UTC Thanks for your response Steven! > (In reply to comment #7) >> cc1 is writing about one line every 2 minutes to its assembler output file: > If you've really configured with --enable-stage1-checking=all, you've enabled .. > All forms of --enable-checking=all are really for debugging purposes only ... > Can you please try without -enable-stage1-checking=all? Fair enough, OK, I will. But I'd still like some kind of answer - why MUST insn-emit.c be so large ? The answer "compiling lots of small .c files is slower that one large one" is demonstrably false on my machine and on many other machines with not much RAM I suspect, and must be qualified with "if you have a platform with X RAM and X CPU speed" . If the gcc build scripts detect they are running on a platform with less than 4GB of RAM, say, they could decide to split insn-emit.c . Why is it so inconceivable that they might in future do something like this ?