From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19001 invoked by alias); 9 Jan 2008 15:57:14 -0000 Received: (qmail 18993 invoked by uid 22791); 9 Jan 2008 15:57:14 -0000 X-Spam-Check-By: sourceware.org Received: from posta.ti-edu.ch (HELO ti-edu.ch) (195.176.176.171) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Jan 2008 15:56:54 +0000 Received: from mail.lu.unisi.ch ([195.176.178.40] verified) by ti-edu.ch (CommuniGate Pro SMTP 5.1.12) with ESMTP id 23753854 for gcc@gcc.gnu.org; Wed, 09 Jan 2008 16:56:51 +0100 Received: from scientist-2.mobile.usilu.net ([192.168.76.110]) by mail.lu.unisi.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jan 2008 16:56:51 +0100 Message-ID: <4784EEB8.9000004@lu.unisi.ch> Date: Wed, 09 Jan 2008 15:57:00 -0000 From: Paolo Bonzini Reply-To: bonzini@gnu.org User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Manuel_L=F3pez-Ib=E1=F1ez?= CC: Paolo Bonzini , Andrew Pinski , =?ISO-8859-1?Q?Ismail_D=F6nmez?= , gcc@gcc.gnu.org Subject: Re: Changes in C++ FE regarding pedwarns to be errors are harmful References: <200801082328.22849.ismail@pardus.org.tr> <200801082345.30788.ismail@pardus.org.tr> <6c33472e0801081428l33bfb4a9vf87e51d8b6b7eaf8@mail.gmail.com> <200801090037.31205.ismail@pardus.org.tr> <4784D5C3.9040508@gnu.org> <6c33472e0801090738n4db8afe0n2c4fdd16746cffa6@mail.gmail.com> In-Reply-To: <6c33472e0801090738n4db8afe0n2c4fdd16746cffa6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00086.txt.bz2 >> Not at all!!! -fpermissive can (in weird cases, agreed) change code >> generation. I'm pretty sure you don't want to risk that only to silence >> an error. > > What? That doesn't make any sense. And it is certainly not documented > in the manual. I will be very interested in an example, no matter how > weird or uncommon. Uhm, I might be confusing it with -ffriend-injection (which is in some sense more permissive than -fno-friend-injection). Reading "in some case name lookup will not be standard conforming" in bkoz's document at http://people.redhat.com/~bkoz/porting_to_gcc43.html added to my confusion. Paolo