From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127910 invoked by alias); 12 Jun 2017 15:54:42 -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 127899 invoked by uid 89); 12 Jun 2017 15:54:42 -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=pose, Hx-languages-length:2408, invest, our 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 15:54:39 +0000 Received: by simark.ca (Postfix, from userid 33) id E4EE11E5A3; Mon, 12 Jun 2017 11:54:42 -0400 (EDT) To: Eli Zaretskii 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=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 12 Jun 2017 15:54:00 -0000 From: Simon Marchi Cc: Yao Qi , simon.marchi@ericsson.com, gdb-patches@sourceware.org In-Reply-To: <83a85d5l4n.fsf@gnu.org> References: <1497124689-11842-1-git-send-email-simon.marchi@ericsson.com> <83tw3n5jyk.fsf@gnu.org> <86tw3labb0.fsf@gmail.com> <83a85d5l4n.fsf@gnu.org> Message-ID: <93eb64489ac9d53665a144ddf5a966d5@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.5 X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00321.txt.bz2 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. - 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. - 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. - linux-low: Remove usage of "register" keyword: That's a good legacy code cleanup in any case, IMHO. - Add ATTRIBUTE_PRINTF to trace_start_error: It's actually a legit warning, I'm surprised GCC itself doesn't warn about that. 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