Comment 8 for bug 398403

This is so very much like my strange experience last year with just a
very specific file in X.org that would similarly balloon gcc memory
usage cross-compiling for powerpc...the solution chosen at the time was
to use 2G or larger build machines ;).

Loïc Minier wrote:
> 19:06 < lool> cjwatson: I built with -O0 -fno-common -fno-foo ... disabling all
> enabled opts until the output would only mention one enabled opt
> which is the reverse of another one; the build still takes
> hundreds of megs of RAM and I stop it at around 80 % RAM after 3
> minutes
> 19:07 < lool> I guess I should have tried with an unpatched gcc though
> ...
> 19:08 < lool> Oh it passed
> 19:08 < lool> after 4 minutes or so
> 19:09 < lool> but using a big load of RAM
> ...
> 19:12 < lool> doko: I don't quite know how to attack the upstart build slowness
> issue
> 19:12 < lool> Basically, we're seeing underperformance, but it's hard to
> qualify how fast gcc should run, or how much memory it's allowed
> to use
> 19:12 < lool> doko: Do you think some patches we're using could be destroying
> performance?
> 19:12 < lool> e.g. that 64 bytes align patch
> 19:13 < lool> That's a binutils patch, but I can see how it could lead to much
> larger RAM usage
> 19:13 < doko> lool: where is the time used, in cc1, or as?
> 19:13 < lool> doko: cc1
> 19:14 < doko> well, then it's not the align patch, and we are pretty much using
> upstream, no fancy patches on our own
> 19:15 < lool> doko: Can I just report it upsteam opening a new bug saying that
> it uses a load of RAM/CPU to build a file?
> 19:15 < lool> ie Is that an acceptable bug?
> 19:16 < doko> lool: sure, better check it with 4.3 (or older) as well to see if
> it's a regression or not.
> ...
> 19:23 < lool> doko: It's about the same performance with gcc-4.3
>