From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96404 invoked by alias); 12 Jun 2017 16:44:26 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 96389 invoked by uid 89); 12 Jun 2017 16:44:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=observe X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Jun 2017 16:44:22 +0000 Received: by simark.ca (Postfix, from userid 33) id 7902C1E5A3; Mon, 12 Jun 2017 12:44:25 -0400 (EDT) To: Andrew Pinski Subject: Re: [PATCH 0/5] Remove a few hurdles of compiling with clang X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 12 Jun 2017 16:44:00 -0000 From: Simon Marchi Cc: Eli Zaretskii , Yao Qi , Simon Marchi , gdb-patches@sourceware.org In-Reply-To: References: <1497124689-11842-1-git-send-email-simon.marchi@ericsson.com> <83tw3n5jyk.fsf@gnu.org> <86tw3labb0.fsf@gmail.com> <83a85d5l4n.fsf@gnu.org> <93eb64489ac9d53665a144ddf5a966d5@polymtl.ca> Message-ID: <5a3de5613db0492e91585ab8497bb3d3@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.5 X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00333.txt.bz2 On 2017-06-12 18:23, Andrew Pinski wrote: > On Mon, Jun 12, 2017 at 8:54 AM, Simon Marchi > wrote: >> - gdb: Pass -x c++ to the compiler: GCC (and even the Intel compiler) >> supports this option too, at worst it's a neutral change for compiling >> with >> GCC. > > Why is this needed? Why can't you use clang++ or similar to force > compiling as C++? Sorry for being unclear. I do use clang++ and it complains: $ clang++ test.c clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated So using -x c++ is the only way I found to make it work (short of renaming the files). >> - gdb: Use -Werror when checking for (un)supported warning flags: it >> just >> forces the behavior to what's already the default with GCC. Again, >> it's >> neutral at worst, at best it protects us if GCC ever decides to change >> its >> default behavior. > > > Yes I think this is ok because gcc also does not warn about > unsupported warning flags unless there is an error. Hmm that's not what I observe: $ gcc test.c $ gcc test.c -Wfoo gcc: error: unrecognized command line option ‘-Wfoo’ >> - gdb: Add -Wno-mismatched-tags: We already have a system that tests >> which >> warning flags are supported by the current compiler, so this flag will >> not >> be included in the builds with GCC. So it's neutral for GCC, and >> improves >> the situation for Clang with almost no effort. > > This warning is a bug in clang and really should not be warned about > in either -Wall or -Wextra. I have been complaining about this since > clang added this option. >> >> - linux-low: Remove usage of "register" keyword: That's a good legacy >> code >> cleanup in any case, IMHO. > > Yes and no. I don't think register was deprecated in C++11. From what I understand, the register keyword has more or less no effect on compilers today, so it would be pretty much useless. So we can remove it and we don't really care. >> >> - Add ATTRIBUTE_PRINTF to trace_start_error: It's actually a legit >> warning, >> I'm surprised GCC itself doesn't warn about that. > > This warning does not make sense. Can you give some more context? Sure, the actual error is: /home/emaisin/src/binutils-gdb/gdb/gdbserver/../nat/fork-inferior.c:582:13: error: format string is not a string literal [-Werror,-Wformat-nonliteral] vwarning (fmt, ap); ^~~ 1 error generated. That code is at: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/nat/fork-inferior.c;h=0913409e6dd01e78019e85068f2e34e8e744ec5b;hb=HEAD#l575 The vwarning function is itself marked with ATTRIBUTE_PRINTF: 31 extern void vwarning (const char *fmt, va_list args) 32 ATTRIBUTE_PRINTF (1, 0); So it makes sense (I think) to complain that the value passed to fmt is not a literal, unless that value is also marked as being a format string. Then it pushes the requirement of passing a literal to the caller. Simon