From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1805 invoked by alias); 20 Sep 2004 20:54:53 -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 1775 invoked from network); 20 Sep 2004 20:54:52 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 20 Sep 2004 20:54:52 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i8KKwFsh021079 for ; Mon, 20 Sep 2004 13:58:15 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Mon, 20 Sep 2004 13:54:51 -0700 Received: from [17.201.24.249] (isolde.apple.com [17.201.24.249]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i8KKsnYG015770; Mon, 20 Sep 2004 13:54:49 -0700 (PDT) In-Reply-To: <414F412C.90504@codesourcery.com> References: <414F37E0.3020509@codesourcery.com> <79845B6C-0B44-11D9-8A65-000A95D7CD40@apple.com> <414F412C.90504@codesourcery.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4FFC8911-0B47-11D9-ADB7-000A95AA5E5E@apple.com> Content-Transfer-Encoding: 7bit Cc: gcc@gcc.gnu.org, Dale Johannesen , Nathan Sidwell , Jason Merrill From: Matt Austern Subject: Re: DR handling for C++ Date: Mon, 20 Sep 2004 21:04:00 -0000 To: Mark Mitchell X-SW-Source: 2004-09/txt/msg01192.txt.bz2 On Sep 20, 2004, at 1:44 PM, Mark Mitchell wrote: > Dale Johannesen wrote: > >> On Sep 20, 2004, at 1:04 PM, Mark Mitchell wrote: >> >>> I think -fpermissive should just be removed. >> >> The eon SPECmark will no longer build if we do that. > > I suppose that's an issue, from a marketing perspective. With my > customer-service hat on, I care a fair amount, as I have customers who > definitely want SPEC numbers. With my GNU maintainer hat on, I don't > care as much. > > It may also be that eon requires a relatively small subset of > functionality presently allowed with -fpermissive. It may also be > that if we do as I suggested (turn some pedwarns into errors, others > into warnings, leave others as pedwarns) that we would be OK because > the issues in question would become warnings, not errors. > > My problem with -fpermissive is only tangentially that it allows us to > compile bogus code; to me, the bigger problem is that it's yet another > knob, and one that is C++ specific. I see no reason why the basic > warnings/errors/pedwarns structure from C should not also be used in > C++. Isn't the fundamental problem that we're using pedwarns differently in the C and C++ front ends? In the C front end you don't even see pedwarns unless you use a special compiler flag, and making them into errors requires an even more special compiler flag. It's very odd that it means something so different in the C++ front end. This is really going off into a different subject (pedwarn policy, not DR policy), but I'd suggest that we: 1. Change the C++ front end's pedwarn defaults to match the C front end's policy. 2. Remove -fpermissive, which #1 will render redundant. 3. Go through our pedwarns and decide which ones should be errors, which ones should be warnings, and which ones really should just be pedwarns. --Matt