[Bug c/54179] please split insn-emit.c !

["jason.vas.dias at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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
?