From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100114 invoked by alias); 12 Jun 2017 16:45:50 -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 99992 invoked by uid 89); 12 Jun 2017 16:45:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f179.google.com Received: from mail-wr0-f179.google.com (HELO mail-wr0-f179.google.com) (209.85.128.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Jun 2017 16:45:39 +0000 Received: by mail-wr0-f179.google.com with SMTP id v111so104179233wrc.3 for ; Mon, 12 Jun 2017 09:45:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=UY6Kx4sFQscwgBe6I6qa/kBGasede9h9I7VZHBKWQSI=; b=UTJ8SsrTJiHSQnRejyHeEJq9bWj9preoOpNjEZDcLqlXTWG6HJCZ2Dz7yZa8NjURjb 8zrElcbDoObMu4tztEB5NqoCi32+Z3aty9bBHqm4dtSubtDc3qiUW+elugm3jgLxy/8d O6NwvgWJXU88SfT/r+pqwJ3kyZU0/G2oLMGJdQQ/fsBPuJJ9kLAg+4S0BafCXSl3AGxO W2f5DCQZHcV4J0fm9LCBX3HODIE83jUfxGzBob7sUeTOh6rk6VkKbgWeHsoJLwruqtAo 9kcaAbcgqJYFprckL25snxCl3YSQ5FOmZI3R/BuDnVaWiTer6kVPCmPbjHEKTu56Rnlv AazA== X-Gm-Message-State: AODbwcAjb9LwoEQtWKtfSEsZa2ApEHX2DNpQsRBTSqwYs7qe/Z82VkTy KIHJsW0jqUlDiErt2JQPrg== X-Received: by 10.80.166.101 with SMTP id d92mr42889051edc.132.1497285937896; Mon, 12 Jun 2017 09:45:37 -0700 (PDT) Received: from [192.168.0.102] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id d1sm5063777ede.46.2017.06.12.09.45.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 09:45:36 -0700 (PDT) Subject: Re: [PATCH 0/5] Remove a few hurdles of compiling with clang To: Andrew Pinski 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> <72d32638-ce7b-d362-5efd-84e8d89431d4@redhat.com> Cc: Simon Marchi , Eli Zaretskii , Yao Qi , Simon Marchi , "gdb-patches@sourceware.org" From: Pedro Alves Message-ID: <5669db7c-e3c1-3aa6-5f78-dca817b44ba1@redhat.com> Date: Mon, 12 Jun 2017 16:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg00335.txt.bz2 On 06/12/2017 05:37 PM, Andrew Pinski wrote: > On Mon, Jun 12, 2017 at 9:35 AM, Pedro Alves wrote: >> On 06/12/2017 05:23 PM, Andrew Pinski wrote: >>> On Mon, Jun 12, 2017 at 8:54 AM, Simon Marchi wrote: >> >>>> - 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. >> >> IIRC, the reason this warning exists is because Microsoft's compilers >> mangle "struct" and "class" differently, so for projects that >> want to be portable to that compiler, it's a helpful warning. >> (Whether that should ever be part of -Wall is a separate matter...) >> >> I don't think we'd want to bend backwards to support MSVC >> though. It's so non-conforming that it's scary. Disabling >> that warning is the right thing to do, IMO. > > Why not have clang disable this warning by default instead? You'll have to ask clang developers. > I am sorry but people who write C++ should understand that they are the same. We know the standard says so, and I know that that's true on the ABIs we care about. But in practice, what compilers (a project cares about) matters more than what the standard says. After all, if the standard says the language does X, but no gcc behaves that way, we wouldn't ever want code to depend on X, would we? Thanks, Pedro Alves