From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18575 invoked by alias); 14 Jan 2008 02:04:16 -0000 Received: (qmail 18332 invoked by uid 22791); 14 Jan 2008 02:04:15 -0000 X-Spam-Check-By: sourceware.org Received: from nz-out-0506.google.com (HELO nz-out-0506.google.com) (64.233.162.236) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Jan 2008 02:03:58 +0000 Received: by nz-out-0506.google.com with SMTP id i11so907066nzh.26 for ; Sun, 13 Jan 2008 18:03:56 -0800 (PST) Received: by 10.142.214.5 with SMTP id m5mr2244421wfg.151.1200276235568; Sun, 13 Jan 2008 18:03:55 -0800 (PST) Received: by 10.143.187.4 with HTTP; Sun, 13 Jan 2008 18:03:55 -0800 (PST) Message-ID: <6c33472e0801131803y51f3e31drbc970db8a9e87e1@mail.gmail.com> Date: Mon, 14 Jan 2008 02:19:00 -0000 From: "=?ISO-8859-1?Q?Manuel_L=F3pez-Ib=E1=F1ez?=" To: "Jonathan Wakely" Subject: Re: Changes in C++ FE regarding pedwarns to be errors are harmful Cc: gcc@gcc.gnu.org In-Reply-To: <4348dea50801131618o4fd5a28brd67b5f555039208a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200801082328.22849.ismail@pardus.org.tr> <4787A0F5.9050904@redhat.com> <20080111171203.GD31668@synopsys.com> <4787AD8B.9080006@codesourcery.com> <4348dea50801121013s33dd45f2r4579693855c005e7@mail.gmail.com> <6c33472e0801121107oe448d6pa7c7c77652b71b19@mail.gmail.com> <4348dea50801121150n52b4f03elde14009d6b6a7a43@mail.gmail.com> <6c33472e0801121928q22765e54ga1707b45e6a6d7a6@mail.gmail.com> <4348dea50801131454w1dc2b12cv72df41654e2bec09@mail.gmail.com> <4348dea50801131618o4fd5a28brd67b5f555039208a@mail.gmail.com> X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00194.txt.bz2 On 14/01/2008, Jonathan Wakely wrote: > On 13/01/2008, Jonathan Wakely wrote: > > > > I think all others should change to permerrors. > > I only meant all others in cp/decl.c of course - here are the remaining files. > Again I've only listed the ones that should remain as pedwarns and > other special cases - most change to permerrors. > Thanks for doing this! > Another interesting one. Variadic templates work in C++98 mode and > are used internally, but currently you have to say -fpermissive to use > them in user code. That flag is *usually* needed for > backward-compatibility, not enabling *future* extensions. That is because we didn't have permerror and the semantics of fpermissive were not clear. Now it is evident that this should be a pedwarn. Wow, you found probably the best example of why the current C++ FE behaviour is confusing. > So is support for variadic templates in -std=gnu98 mode an official > extension, or a detail not-for-public-consumption? Well, right now you can use it if you use fpermissive, so if it wasn't for public-consumption, using pedwarn instead of error was not the right thing in the first place. So pedwarn. > I think for consistency with the new proposed behaviour it should > check flag_permissive, instead of !flag_pedantic_errors, do you agree? > Yes, this is the type of thing I am looking when reviewing your suggestions, since they are a potential source of bugs. In my patch I changed a few. > In cp/typeck.c the pedwarns guarded by pedantic should stay as pedwarns. > on line 5356 there is: > if (pedantic) > /* Only issue a warning, as we have always supported this > where possible, and it is necessary in some cases. DR 195 > addresses this issue, but as of 2004/10/26 is still in > drafting. */ > warning (0, "ISO C++ forbids casting between pointer-to-function and > pointer-to-object"); > > This could switch to a pedwarn, since that will still be a warning > under the permerror proposal. That would mean it can be turned into a > fatal error with -pedantic-errors instead of -Werror, which would be > consistent with other warnings that are only enabled by -pedantic. > I'm not sure how "conditionally-supported behaviour" should interact > with -pedantic-errors so let's leave as a warning for now. This is another example of trying to workaround the wrong default of pedwarns. This should be a pedwarn. The reason why is a warning is that pedantic-errors was active by default and that didn't make sense. We are changing this, so we don't need this hack anymore. > Is that all of them? Would you prefer a patch to make the changes or > are you going to go through them yourself anyway? I agree with all your other suggestions. I will try to go through them in the following days and submit a follow-up patch to the ones already submitted. Many thanks! That was impressive. Manuel.