From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103829 invoked by alias); 13 Jun 2017 10:44: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 102771 invoked by uid 89); 13 Jun 2017 10:44:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=caring, Hx-languages-length:2985, handful, tracker 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 ESMTP; Tue, 13 Jun 2017 10:44:34 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 82A4B7D50D; Tue, 13 Jun 2017 10:44:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 82A4B7D50D Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 82A4B7D50D Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id B5E7C9EB4C; Tue, 13 Jun 2017 10:44:35 +0000 (UTC) Subject: Re: [PATCH 0/5] Remove a few hurdles of compiling with clang To: Yao Qi , Eli Zaretskii 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> <83wp8h40lo.fsf@gnu.org> <8660g0dzau.fsf@gmail.com> Cc: Simon Marchi , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <73cdd28f-8f6b-0367-f054-834477d16754@redhat.com> Date: Tue, 13 Jun 2017 10:44: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: <8660g0dzau.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg00366.txt.bz2 On 06/13/2017 10:14 AM, Yao Qi wrote: > Eli Zaretskii writes: > >> That's precisely the reason why I raised this: it would be good to >> have a clear policy on this, to avoid the need for unnecessary work >> and unnecessary disputes. (I actually hoped we already did have such >> a policy, but if not, I think we should try to come up with it.) > > In general, it is good to keep GDB built by different popular compilers, > so people are easy to build GDB and different warnings from different > compilers will catch more bugs in GDB. On the other hand, GCC is still > the primary compiler to build GDB, and support of other compilers in > building GDB should not undermine the case that GDB is built by GCC. > For example, it is not acceptable to build GDB with compiler X but break > the build with GCC. We still must fix the GDB build failure with GCC, as > what we did in the past, and we welcome the contributions to fix the GDB > build with other compilers. I'm fine with that, as long as other compilers don't unreasonably hold us back, when GCC is an option, and the user base that'd want to actually use such a compiler is small. E.g., maintenance effort, and migration to newer language revisions. Here I don't specifically mean Clang, but in general. E.g., exaggerating to illustrate a point, if someone wanted to port GDB to OddballPlatform used by to handful of people in the world, and that requires building with a 10-year-old compiler that nobody's maintaining, then I think it'd be unreasonable for everyone upstream to have to keep such a port in mind and consider whether such a port would get broken by some GDB patch or design change. Other popular compilers nowadays tend to support "GNU C/C++" and impersonate as GCC (define __GNUC__, etc.), so porting effort tends to not be that big in practice, fortunately. The MSVC compiler issue came up in the -Wno-mismatched-tags discussion, and I think my statements may have sounded too strongly against MSVC. If someone wants to make GDB buildable with Visual Studio for some reason, I'd personally be OK with that, as long as that doesn't involve uglifying the codebase, or holding back migration to newer language revisions. Modern versions are getting better at standards compliance and gnulib supports MSVC (ISTR there's some command line compiler wrapper that makes it possible to run configury with msvc), so it may actually be doable. I don't know why would someone want to do it, though. But until someone seriously steps forward and commits to maintaining such a port, caring about "-Wmismatched-tags" warnings is useless, since I suspect that issue would be the least of the porting effort troubles. BTW, on the different warnings, IMO, ideally every bug that Clang finds in the code that GCC didn't warn about should be considered a GCC bug, and we should make sure that it's reported on the GCC tracker. Thanks, Pedro Alves