From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11923 invoked by alias); 23 Apr 2002 20:59:23 -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 11861 invoked from network); 23 Apr 2002 20:59:19 -0000 Received: from unknown (HELO vexpert.dbai.tuwien.ac.at) (128.130.111.12) by sources.redhat.com with SMTP; 23 Apr 2002 20:59:19 -0000 Received: from pulcherrima (pulcherrima [128.130.111.23]) by vexpert.dbai.tuwien.ac.at (8.11.6/8.11.6) with ESMTP id g3NKxIW02803; Tue, 23 Apr 2002 22:59:18 +0200 (MET DST) Date: Tue, 23 Apr 2002 14:21:00 -0000 From: Gerald Pfeifer To: gcc@gcc.gnu.org cc: Mark Mitchell , Joe Buck Subject: Re: GCC 3.1 Prerelease In-Reply-To: <200204231632.JAA20650@atrus.synopsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-04/txt/msg01200.txt.bz2 On Tue, 23 Apr 2002, Mark Mitchell wrote: > I don't think we're in a position to do much at this point. The numbers > look only slightly different from GCC 3.0.x. What most worries me is the following part of my report: | Compiling the file attached to PR 3083/C++ takes 62.4s with the 3.1-branch | versus 46.9s with GCC 3.0.3 (on a PIII/1000). This is a slowdown by one third or 33% from 3.0.3 to the 3.1-branch! > I agree that we should investigate these issues, but I don't think we > should hold up the release to try to work on them. It's a bit frustrating that the high priority PR with this testcase is now over 10 months old, but I agree we shouldn't hold up the release just because of this issue. It would be nice, though, if someone could have a look to see whether there's some easy fish to be caught there. On Tue, 23 Apr 2002, Joe Buck wrote: > Any fixes will probably need architectural changes that will need > extensive testing, so it really isn't feasible. Well, perhaps some of the improvements are not too intrusive and could be backported in time for 3.1.1 after a period of testing on mainline? > If we're going to do something, I think that we should consider > insisting on performance improvements in 3.2, otherwise we do mandatory > schedule slips for as long as it takes. There's no point in continuing > down the track we're on: releases that take longer and longer to compile > code that is no better. Agreed! (Though ideally the problem will be attacked much sooner, that is, before 3.2 branches.) > I think Gerald's right: [...] It's kind of relieving to see that I'm not the only experiencing this kind of problem; sometimes I've been wondering whether I was doing something stupid... Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/