From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5451 invoked by alias); 13 Jan 2004 00:55:22 -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 5433 invoked from network); 13 Jan 2004 00:55:21 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 13 Jan 2004 00:55:21 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id i0D0tKou006028 for ; Mon, 12 Jan 2004 16:55:20 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Mon, 12 Jan 2004 16:55:20 -0800 Received: from [17.201.24.57] (polskifiat.apple.com [17.201.24.57]) by relay3.apple.com (8.12.10/8.12.9) with ESMTP id i0D0tKIE005943; Tue, 13 Jan 2004 00:55:20 GMT In-Reply-To: <20040113004557.GB23342@atrey.karlin.mff.cuni.cz> References: <90200277-4301-11D8-BDBD-000A95B1F520@apple.com> <200401130118.27506.s.bosscher@student.tudelft.nl> <200401130140.09367.s.bosscher@student.tudelft.nl> <20040113004557.GB23342@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <37316DE4-4563-11D8-B7FE-000393673036@apple.com> Content-Transfer-Encoding: 7bit Cc: Phil Edwards , Steven Bosscher , gcc@gcc.gnu.org, Geoff Keating , Mark Mitchell From: Ziemowit Laski Subject: Re: gcc 3.5 integration branch proposal Date: Tue, 13 Jan 2004 00:55:00 -0000 To: Jan Hubicka X-SW-Source: 2004-01/txt/msg00765.txt.bz2 On 12 Jan, 2004, at 16.45, Jan Hubicka wrote: >> On Tuesday 13 January 2004 01:23, Ziemowit Laski wrote: >>> On 12 Jan, 2004, at 16.18, Steven Bosscher wrote: >>>> On Tuesday 13 January 2004 01:11, Ziemowit Laski wrote: >>>>> On 12 Jan, 2004, at 15.49, Mark Mitchell wrote: >>>>>> Apple (and some other vendors, including CodeSourcery) is in the >>>>>> position of doing its own release management and bug-fixing based >>>>>> on >>>>>> various versions of GCC. Therefore, having high-quality FSF >>>>>> releases >>>>>> may not make much of a difference to Apple; Apple doesn't use it >>>>>> directly anyhow. >>>>> >>>>> And the reason we don't is because the FSF keeps shooting down our >>>>> patches. >>>>> You just can't have it both ways. >>>> >>>> And Apple keeps ignoring existing infrastructure. I understand the >>>> inconvenience for you, but you should _fix_ patches, not force in. >>> >>> Please explain what you mean by 'infrastucture' and just how evil >>> Apple >>> is ignoring it. >> >> Not evil. I never said that. I wish I had an Apple. Ask Pinski, >> he knows ;-) >> >> What I mean is that most patches I've seen so far were shot down on >> technical grounds, on bad timing (stage3), for not using existing >> functions to perform certain actions (feedback-based prefetching), >> apparently patents (?) for hot/cold, etc. > > One of causes of this is the fact that we happent to conflict in an > efforts (prefetching, new inlining were both developed independently > twice). This is real shame as many of features Apple compiler has > would > be very, very nice to have in mainline but merging is getting > increasingly dificult. > It would be great to simply use FSF CVS branch for Apple enhancements > and post patches to gcc-patches as they are being developed or released > to public. > > That would make it much easier to notice such an infrastructural > conflicts much earlier. I know I can watch Apple's CVS (is there some > mainling list?) and I will try to do it in future, but it would be > easier if this went in as other patches commonly do. That's actually a very good point. I'll forward this internally to the powers that be for consideration. --Zem -------------------------------------------------------------- Ziemowit Laski 1 Infinite Loop, MS 301-2K Mac OS X Compiler Group Cupertino, CA USA 95014-2083 Apple Computer, Inc. +1.408.974.6229 Fax .5477