From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21163 invoked by alias); 16 Mar 2004 02:09:06 -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 21154 invoked from network); 16 Mar 2004 02:09:05 -0000 Received: from unknown (HELO smtp3.libero.it) (193.70.192.127) by sources.redhat.com with SMTP; 16 Mar 2004 02:09:05 -0000 Received: from bagio (151.37.74.50) by smtp3.libero.it (7.0.027-DD01) id 404F148A00167252; Tue, 16 Mar 2004 03:09:03 +0100 Message-ID: <04f201c40afb$a69f8e00$074e2a97@bagio> From: "Giovanni Bajo" To: Cc: References: <200403091809.i29I9P04020607@sirius.codesourcery.com> Subject: C++ status (Was: GCC Status Report (2004-03-09)) Date: Tue, 16 Mar 2004 02:09:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00765.txt.bz2 Mark Mitchell wrote: > Furthermore, please do not create any new PRs targeted for 3.4 without > my explicit permission. If it's a regression, target it for 3.4.1. > If you think it might need to be fixed in 3.4, add me to the CC list, > and add a note asking me to move back the target. Please do not do > this unless the PR is wrong-code, ICE-on-valid, or bootstrap for a > primary target. New PRs referring to other categories of error are > simply not going to get fixed for 3.4. Mark, I understand your concerns to stabilize the 3.4 branch. Alas, at least from a C++ point of view, it seems that the branch is nowhere near being stable. To get some numbers, I tried counting the number of C++ regressions that were found out and submitted since the beginning of February till today: they are 50, which roughly means one new regression uncovered each day (and yes, *valid* regressions, I'm not counting bogus bug reports). Even if most of them are usually handled within the same week they are submitted, this number is not getting down yet. The more we fix, the more we uncover. I assume that this number will have to decrease sooner or later, but this does not the case right now. My suggestions: - I would strongly recommend 1-2 weeks of C++ freeze before release, to make sure at least all important packages (the ones in the criteria) get properly tested. This would help making sure that late patches did not uncover some regressions. For instance, every other patch to the C++ frontend seems to break Boost.Python somehow. Their authors are very prompt at testing and submitting the new problems, though. - Is it possible to at least get back all new C++ rejects-valid regressions to a default 3.4.0 target? They look really important to me, especially since the new parser is much strictier, so people will have already enough code to modify. For the longer run, I think the big problem is that the current g++ testsuite (+ v3 testsuite) is not enough for testing C++ patches. I suggest we incorporate bigger preprocessed sources from open source packages. I'm actually already working on this, as Diego showed interest in having those in tree-ssa before the merge for the benefit of additional testing. Giovanni Bajo