From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21689 invoked by alias); 9 Mar 2004 18:09:27 -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 21682 invoked from network); 9 Mar 2004 18:09:26 -0000 Received: from unknown (HELO sirius.codesourcery.com) (65.74.133.4) by sources.redhat.com with SMTP; 9 Mar 2004 18:09:26 -0000 Received: from sirius.codesourcery.com (localhost.localdomain [127.0.0.1]) by sirius.codesourcery.com (8.12.8/8.12.5) with ESMTP id i29I9PIu020642 for ; Tue, 9 Mar 2004 10:09:25 -0800 Received: (from mitchell@localhost) by sirius.codesourcery.com (8.12.8/8.12.8/Submit) id i29I9P04020607; Tue, 9 Mar 2004 10:09:25 -0800 Date: Tue, 09 Mar 2004 18:09:00 -0000 Message-Id: <200403091809.i29I9P04020607@sirius.codesourcery.com> From: Mark Mitchell To: gcc@gcc.gnu.org Subject: GCC Status Report (2004-03-09) Reply-to: mark@codesourcery.com X-SW-Source: 2004-03/txt/msg00463.txt.bz2 [I tried to send this out last night, but apparently failed.] GCC 3.4 ======= Unfortunately, although progress was made last week, we still have a ways to go. We're down to 48 regressions targeted at 3.4.1, down from 57. Some of those have patches that I've approved for 3.4, but there are a lot that do not. We're not ready to spin prerelease bits yet. I'd particularly like to understand this RTX_UNCHANGING_P optimization issue. We've bumped into this before. I think we need to take the conservative approach, even if that is pessimizing in some case. Would someone who understands the details of this bug please summarize it, mail that to me, and also add that information to the appropriate PR? Some of the other PRs also look pretty significant. I'll continue to beat on the C++ issues, but there are serious issues with debugging (13974) and with wrong code (14381, 14470, 12863, 13424, 13632). Henceforth, please do not make any non-documentation check-ins to the 3.4 branch without my explicit approval. To get that approval, please do *not* send me mail directly. Instead, add your patch to the relevant PR, which must be targeted at 3.r, and add me to the CC list for the PR. Note that this procedure implies that if there is no PR targeted at 3.4 I will not accept the patch. 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. GCC 3.5 ======= In a holding pattern until tree-ssa merge is complete. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com