From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19571 invoked by alias); 12 Jun 2017 16:55:20 -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 19532 invoked by uid 89); 12 Jun 2017 16:55:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:3670 X-HELO: mail-yb0-f171.google.com Received: from mail-yb0-f171.google.com (HELO mail-yb0-f171.google.com) (209.85.213.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Jun 2017 16:55:15 +0000 Received: by mail-yb0-f171.google.com with SMTP id o9so28244310yba.3 for ; Mon, 12 Jun 2017 09:55:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=O6BOMxEJqqhn/F8a75LLq5XEUVtkQnTFxUJo7NbYFzc=; b=ZrI87N/beQhy8a2fZp/ENapgYoimQXi2dCJ0cAl6XxAWI+c+0GuRuj9/Rr8Tdgven9 NMsMfAX/38rrVNhVaYQMlNE0AWiEzYy8XfZBMgfdnyeUAQcWisHa0ZK+SNUrRSpHndvc H6XiuA3xlPYK0MjEGuAV3wa0pZpiKo/nbYUCZpjjPalPos2kiYu3OEta6bfETD1XA9Q8 6YhW9K6CMbntoQKcQW0OBTh+XyRDS0tksfxgERD1Zg+k8nkdU2Lk+nAuAzboEfGJ1fVx tNQJb4KTrg4jy3mDGfTvy94Yverdh6UPD0E8ppQvZ87CbeX2b1tmOgNVCIK/vQ88OUir korQ== X-Gm-Message-State: AODbwcBqeh9NVlsSdsDcYd6k9+rLWPMPovcnHu23nq/bJRLQAYQsk23B wy2uQpawqQFrPltO+DT2IndS4EwQwA== X-Received: by 10.37.231.205 with SMTP id e196mr23891234ybh.88.1497286518299; Mon, 12 Jun 2017 09:55:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.47.200 with HTTP; Mon, 12 Jun 2017 09:55:17 -0700 (PDT) In-Reply-To: <5a3de5613db0492e91585ab8497bb3d3@polymtl.ca> 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> <5a3de5613db0492e91585ab8497bb3d3@polymtl.ca> From: Andrew Pinski Date: Mon, 12 Jun 2017 16:55:00 -0000 Message-ID: Subject: Re: [PATCH 0/5] Remove a few hurdles of compiling with clang To: Simon Marchi Cc: Eli Zaretskii , Yao Qi , Simon Marchi , "gdb-patches@sourceware.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00337.txt.bz2 On Mon, Jun 12, 2017 at 9:44 AM, Simon Marchi wro= te: > 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 behavi= or > is deprecated > > So using -x c++ is the only way I found to make it work (short of renaming > the files). Why is it deprecated? I don't see a reason for that. > >>> - 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 =E2=80=98-Wfoo=E2=80=99 Oh right GCC does error out about the positive case, it is the negative case -Wno-foo it does not error out for. > > >>> - 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. I am saying clang is broken here to some extend. It is warning about something which is not deprecated. The fix is correct just I am saying clang's warning is not correct. > >>> >>> - 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:1= 3: > 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=3Dbinutils-gdb.git;a=3Dblob;f=3Dg= db/nat/fork-inferior.c;h=3D0913409e6dd01e78019e85068f2e34e8e744ec5b;hb=3DHE= AD#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 n= ot > a literal, unless that value is also marked as being a format string. Th= en > it pushes the requirement of passing a literal to the caller. Oh, the warning is a bit weird and worded incorrectly for this case. the fix is correct though. Thanks, Andrew > > Simon