From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53941 invoked by alias); 16 Dec 2015 22:10:58 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 53931 invoked by uid 89); 16 Dec 2015 22:10:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=sk:warning, Hx-languages-length:1296 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 16 Dec 2015 22:10:55 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id ACB13C0B930A; Wed, 16 Dec 2015 22:10:54 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBGMAqkp023325; Wed, 16 Dec 2015 17:10:53 -0500 Message-ID: <5671E16C.1080907@redhat.com> Date: Wed, 16 Dec 2015 22:10:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Simon Marchi CC: "Jose E. Marchesi" , Yao Qi , "gdb@sourceware.org" Subject: Re: C++ conversion status update References: <565460FB.6070103@redhat.com> <86zixdnlfg.fsf@gmail.com> <566F13D4.9000900@redhat.com> <877fkglytf.fsf@oracle.com> <5671C65E.3070503@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-12/txt/msg00024.txt.bz2 On 12/16/2015 08:29 PM, Simon Marchi wrote: > On 16 December 2015 at 15:15, Pedro Alves wrote: >> Simon, do you see this one? > > Yes, but it doesn't seem to make the compilation fail on its own > (despite stating it's an error). I only see it when the build fails > because of another error. I figured that that flag was introduced gcc > version, and that it doesn't hurt if it's not recognized. Ah, yes, that's it. We have code in configure.ac that tries to detect whether the compiler supports each warning and suppress it it no, but it's getting fooled by: "When an unrecognized warning option is requested (e.g., -Wunknown-warning), GCC emits a diagnostic stating that the option is not recognized. However, if the -Wno- form is used, the behavior is slightly different: no diagnostic is produced for -Wno-unknown-warning unless other diagnostics are being produced. This allows the use of new -Wno- options with old compilers, but if something goes wrong, the compiler warns that an unrecognized option is present." That's from https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html. I think we can handle this by making that warning-support test code check whether -Wfoo works when we actually want -Wno-foo. Thanks, Pedro Alves