From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52545 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q0yg7-0004p8-Do for qemu-devel@nongnu.org; Sat, 19 Mar 2011 12:07:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q0yg4-0003IQ-WD for qemu-devel@nongnu.org; Sat, 19 Mar 2011 12:06:59 -0400 Received: from lo.gmane.org ([80.91.229.12]:53006) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q0yg4-0003I6-La for qemu-devel@nongnu.org; Sat, 19 Mar 2011 12:06:56 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q0yg1-0000Ub-B4 for qemu-devel@nongnu.org; Sat, 19 Mar 2011 17:06:53 +0100 Received: from adsl-69-234-181-38.dsl.irvnca.pacbell.net ([69.234.181.38]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Mar 2011 17:06:53 +0100 Received: from w41ter by adsl-69-234-181-38.dsl.irvnca.pacbell.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Mar 2011 17:06:53 +0100 From: walt Date: Sat, 19 Mar 2011 09:06:31 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: Subject: [Qemu-devel] Re: git commit c832e3de chokes gcc-4.5.2 (out of memory error) List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 03/18/2011 03:44 PM, Peter Maydell wrote: > On 18 March 2011 23:31, walt wrote: >> The following commit has a strange side-effect on gcc-4.5.2: >> The new code in 'target-i386/translate.c' compiles just fine with gcc-4.4.4, >> using less than 1GB of RAM, but gcc-4.5.2 uses the whole GB and then fills >> up 2GB of swap space in addition while the machine grinds slowly to a halt. > > I'm wondering whether this is > https://bugs.launchpad.net/gcc-linaro/+bug/714921 > again (an upstream gcc bug, fix in-progress). > >> I'm hoping someone here might know how to find the source of the problem >> so I can add some helpful details to my bug report. > > 1. If you compile with -fno-var-tracking does it still use lots > of memory? That flag fixes the memory problem, so my bug must be the same, I think. > 2. (for the ludicrously enthusiastic only) build a gcc with the patches > listed in that bug report and see if the problem goes away... I fetched the patch and found that it doesn't apply cleanly to the heavily patched gentoo sources :( Many thanks for the excellent clue.