From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26434 invoked by alias); 24 Apr 2009 15:04:31 -0000 Received: (qmail 26044 invoked by uid 22791); 24 Apr 2009 15:04:27 -0000 X-SWARE-Spam-Status: No, hits=3.1 required=5.0 tests=AWL,BAYES_20,BOTNET,SPF_PASS X-Spam-Check-By: sourceware.org Received: from vms173007pub.verizon.net (HELO vms173007pub.verizon.net) (206.46.173.7) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Apr 2009 15:04:22 +0000 Received: from [10.10.1.168] ([209.190.166.162]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KIM00INM1UXL3UB@vms173007.mailsrvcs.net> for gcc-help@gcc.gnu.org; Fri, 24 Apr 2009 10:04:09 -0500 (CDT) Message-id: <49F1D4FC.2030500@verizon.net> Date: Fri, 24 Apr 2009 15:04:00 -0000 From: John Fine User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-version: 1.0 To: gnu Cc: Ian Lance Taylor Subject: Re: internal compiler error: in avail_expr_eq, at tree-ssa-dom.c:2055 References: <49EEA92A.8090306@redpinesignals.com> <49EF2423.6030207@redpinesignals.com> <49EFFD58.8000407@redpinesignals.com> <49F05AD4.7040900@verizon.net> <49F10E89.5050602@verizon.net> In-reply-to: Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2009-04/txt/msg00358.txt.bz2 I want to be sure I really understood you on that point. The internal garbage collector is influenced by physical ram use by other processes? This in not an issue of virtual memory limits in the current process (it is AMD64 and VIRT is under2GB). This is not an issue of system wide commit level (the swap space is slightly larger than the VIRT total across all processes, and not all of that VIRT even needs one of physical ram or swap, and there is 8GB of physical ram). But physical ram is somewhat low (the compiles each have slightly lower RES memory than the same compile would have if it were running alone and cache is much lower, so .hpp files are being reread rather than always found in cache). Do you happen to know what method the internal garbage collector uses to ask about physical ram in order to be affected by it? I understand how hard it would be to look for a bug that depends on garbage collector choices in a very big compile. So I guess I should be very glad the compiler crashes rather than silently producing wrong results. But I would like a better understanding myself of what influences compiler behavior. Ian Lance Taylor wrote: > No. However, gcc's internal garbage collector does make such decisions. > This is not supposed to affect the compiler's output, but of course if > there is a bug it might. > >