From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32121 invoked by alias); 19 Jan 2004 01:31:26 -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 32098 invoked from network); 19 Jan 2004 01:31:21 -0000 Received: from unknown (HELO nef.ens.fr) (129.199.96.32) by sources.redhat.com with SMTP; 19 Jan 2004 01:31:21 -0000 Received: from quatramaran.ens.fr (quatramaran.ens.fr [129.199.129.64]) by nef.ens.fr (8.12.10/1.01.28121999) with ESMTP id i0J1VDaW007326 ; Mon, 19 Jan 2004 02:31:13 +0100 (CET) Received: by quatramaran.ens.fr (Postfix, from userid 561) id 044D74895; Mon, 19 Jan 2004 02:31:13 +0100 (CET) To: geoffk@apple.com Subject: Re: gcc 3.5 integration branch proposal In-Reply-To: References: <90200277-4301-11D8-BDBD-000A95B1F520@apple.com> <20040110002526.GA13568@disaster.jaj.com> <82D6F34E-4306-11D8-BDBD-000A95B1F520@apple.com> <20040110154129.GA28152@disaster.jaj.com> <1073935323.3458.42.camel@minax.codesourcery.com> <1073951351.3458.162.camel@minax.codesourcery.com> Organization: Cc: gcc@gcc.gnu.org Message-Id: <20040119013113.044D74895@quatramaran.ens.fr> Date: Mon, 19 Jan 2004 01:31:00 -0000 From: espie@quatramaran.ens.fr (Marc Espie) X-SW-Source: 2004-01/txt/msg01231.txt.bz2 In article you write: >I think that the release manager holding up GCC development for months >in order to achieve an arbitrary regression goal is inappropriate, >especially if this comes at the cost of other goals (most notably, >timeliness) of one or more releases. In particular, I think that your >excessive focus on avoiding regressions is contributing to GCC's >serious problems in other areas, most notably speed of compilation and >speed of generated code when compared against the best available >commercial compilers (for me, that's CodeWarrior and icc/xlc >respectively, and we're about 60% and 25% behind respectively). Speaking for various people in the OpenBSD project, the current compiler speed is completely catastrophic. What is very, very bad, is that I've seen wishful thinking messages on this list that were announcing the speed issue was going to be taken care of, but it didn't happen so far. We are not following every release, and I am seeing increasing reluctance wrt updating to a more recent version of GCC. I do see the benefits, sure (I love the new preprocessor, except for the -traditional bug, and I really need a standard C++ compiler), but updating from 2.8.1 to 2.95 slowed our compiles by ~30%, and the on-going 2.95 to 3.3.2 update is slowing them by 30% more. Heck, we do have architectures that are NOT going to switch because the compile are really too slow now. There's even some chance only sparc64 will switch because 2.95 was completely crap on sparc64 (understandably so). And I still see absolutely NOTHING that shows that the compile time is going to go down at some point in the future. pre-compiled headers, tree-ssa, all this are fine ideas, but judging by past record, I now seriously doubt that people who say GCC compile time is going to improve are doing anything but selling a blatant lie. I won't accuse them of doing that knowingly, of course. But seriously, the only claim of speed improvements I've seen that had any kind of foundation was the inline `improvement', where the current compiler as almost gone back to a par with the previous inlining speed, before it went from rtl to function-at-a-time. This is more and more of a serious problem. As a specific instance, I've been working on an attribute extension that I had to port from 2.95 to 3.3.2, and I have real trouble seeing how the `new' attribute infrastructure is an improvement on the old one. The code isn't especially easier to read, and it replaces simple enums with an attribute tree that gets parsed *each time* it's applied to a node. Sure, it's a tiny difference. But if a large part of the GCC development consists of such tiny steps, well, it's not hard to say where the compile time is going.