From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2110 invoked by alias); 12 Jun 2017 16:23:36 -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 2096 invoked by uid 89); 12 Jun 2017 16:23:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=pose, invest X-HELO: mail-yw0-f195.google.com Received: from mail-yw0-f195.google.com (HELO mail-yw0-f195.google.com) (209.85.161.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Jun 2017 16:23:34 +0000 Received: by mail-yw0-f195.google.com with SMTP id w143so6500283yww.1 for ; Mon, 12 Jun 2017 09:23:38 -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; bh=CqFh5UWVaWzofiVURXSEKfISFF92z8g9n2PHOkBRHMk=; b=RW+pE20bq3ov5jaRKyKh6a7/P7VXzWs4B4Q6QXgRaNbwf1RhawCIGs2t9JE9qPw7sT zRG2MdCvsQDJTCPEHq16ZZEY9aUNdt6UaTyFp3GBX1so/RBM+i1433aoaU/UAWJnreIP MQL86BVyTXAKXzsOec1SFvTM/hv6vVSJCMgVqxlQwYy+ZaTIy3Jr9IPJnYvFuTycvgAc 1ezA7olaY9jZlI9N6Nx3Qewf5fhP7dQFW41MjtR65i9HIouQMrMVhZTPPZuOi0/FhCQZ KlW4UN1wLwNdNKPMp2l+rFwXRDYk73av9sdxhAJgEYB+MtgFdNjCv38hsj6LuIWnYJ7I UlzQ== X-Gm-Message-State: AODbwcAFvQEoK+6fVPBGW8iVTtLLHjOphkXmwOgF79LBm7oIJgOJ6Ctv kcyf8Yrv66gTOMp9NZjfnm4kwJMJaA== X-Received: by 10.129.156.194 with SMTP id t185mr13117430ywg.169.1497284617092; Mon, 12 Jun 2017 09:23:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.47.200 with HTTP; Mon, 12 Jun 2017 09:23:36 -0700 (PDT) In-Reply-To: <93eb64489ac9d53665a144ddf5a966d5@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> From: Andrew Pinski Date: Mon, 12 Jun 2017 16:23: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" X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00330.txt.bz2 On Mon, Jun 12, 2017 at 8:54 AM, Simon Marchi wrote: > On 2017-06-12 16:35, Eli Zaretskii wrote: >> >> That's not the issue: AFAIU, GDB already builds with clang. >> >> The issue is how much effort would we want to invest for that, and >> what are we willing to give up when using GCC to be able to use other >> compilers. For example, the proposed patch adds an explicit "-x c++" >> switch to _all_ compilations, and also tweaks the warning switches. >> I'm not sure we want GCC builds to be affected so that clang builds >> could be cleaner. But maybe we have a policy about this which deems >> these issues acceptable? > > > Hi Eli, > > I included in this patchset the changes that I think improve the situation > with Clang, but are neutral to GCC, so I don't think these should pose any > problem. Here is what I have to say about each patch: > > - 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++? > > - 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. > > - 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. > > - 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? Thanks, Andrew > > But I think it's a good thing to discuss how far we're willing to go to make > GDB build cleanly with Clang, because some other issues are not so easily > resolved. Some warnings are a bit silly and don't provide much value (e.g. > [1] or -Wmismatched-tags), so it may not make sense to go too far out of our > way to make it happy. > > I think it's also good to have this discussion because of how relevant Clang > is nowadays. A big number of software developers are on OS X/macOS, on > which Clang is the default compiler (shipped with Xcode). Making the source > more Clang-friendly removes a barrier to them contributing to GDB. > > Simon > > [1] https://bugs.llvm.org//show_bug.cgi?id=22712#c1