From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7960 invoked by alias); 2 Apr 2004 19:16:34 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 7892 invoked from network); 2 Apr 2004 19:16:32 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sources.redhat.com with SMTP; 2 Apr 2004 19:16:32 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i32JJlCw022630; Fri, 2 Apr 2004 11:19:47 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Fri, 2 Apr 2004 11:16:31 -0800 Received: from [17.112.104.119] ([17.112.104.119]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id i32JGSrL028669; Fri, 2 Apr 2004 19:16:29 GMT In-Reply-To: References: <20040303083528.14400.schmid@snake.iap.physik.tu-darmstadt.de> <20040401011718.8875.qmail@sources.redhat.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3E8711F6-84DA-11D8-98AA-000A95B1F520@apple.com> Content-Transfer-Encoding: 7bit Cc: gcc@gcc.gnu.org, gcc-bugzilla@gcc.gnu.org From: Geoffrey Keating Subject: Re: [Bug pch/14400] Cannot compile qt-x11-free-3.3.0 Date: Fri, 02 Apr 2004 19:16:00 -0000 To: Ian Lance Taylor X-SW-Source: 2004-04/txt/msg00137.txt.bz2 On 02/04/2004, at 7:17 AM, Ian Lance Taylor wrote: > "geoffk at apple dot com" writes: > >> On Mar 29, 2004, at 11:06 PM, Ian Lance Taylor wrote: > >>> PR 14206 is fixed on mainline by RTH's patch. For 3.4 I put in a doc >>> fix. > >> I've now caught up enough that I read RTH's patch (I've been on >> vacation). Yes, that patch should fix this problem too. I'd suggest >> backporting it to 3.4. > > We can do that. However, I am still troubled by the fact that the > default fallback for gt_pch_get_address/gt_pch_use_address is > unreliable. RTH's patch may well fix the problem on GNU/Linux for all > but strange cases. But it seems to me that with that patch PCH will > work reasonably on GNU/Linux and on Darwin, but will not work reliably > on any other system. > > That is, I don't think that any system can reliably use > mmap_gt_pch_get_address/mmap_gt_pch_use_address, although they are the > default functions on a system which supports mmap. > > Is it better to have PCH which unpredictably fails or PCH which > reliably fails? Right now, in mainline, I think we have the former, > except on GNU/Linux and Darwin. I think that PCH that fails on one case out of a thousand is better than PCH that fails in one thousand cases out of one thousand. However, it would be better if we could make failure even less frequent by tweaking the heuristic. Ian, you've studied the problem, do you have any suggestions for a better heuristic? Maybe gt_pch_get_address should map, say, 32M of unused memory before trying to allocate space for the PCH.