From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31136 invoked by alias); 7 Feb 2014 23:12:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 31122 invoked by uid 89); 7 Feb 2014 23:12:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f177.google.com Received: from mail-ob0-f177.google.com (HELO mail-ob0-f177.google.com) (209.85.214.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 07 Feb 2014 23:12:31 +0000 Received: by mail-ob0-f177.google.com with SMTP id wp18so4743190obc.8 for ; Fri, 07 Feb 2014 15:12:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jeY8RupHQaw/VHrVrfTXda21aYMh0J5mR7BYGaQsim4=; b=IxfGXsQK6qJgFn/hx9V7mTTxmmx4hrvFOZP0BNcll66ct04NraLGh/VrCemMAB4hnr tJDyi7ki8deJcGXytmyMVZtxqIWzi8zLlLJ6UTvHUqfFjHgq1gyQf50H/G9Lu4aK9Zee 1NvZJuoRzPfcYEcSHOURojUm4HlQvVPiigq+KkckXITkWqZIY8hn5wed4CQ5ICGQJxJ8 OQ9hP31UYp1WMsjD+/8ZoiixIbNCnvvL+hpDeiIxC7hGmlxMsDQLTbHLezwxfbEUBzY1 UoPra+UW4X1RxdDcuTw0Lzbr4BNcGat4CWhAD6Ce2qCVvCJ/9m7DAfGmpD3OSXQ6sHx5 sJow== X-Gm-Message-State: ALoCoQnanN+Otf6ISI/lqua8qJQOwwIuY5a9LQocfhWkQ8QDY2fhjlcxyVUWOLJLDIBBiCsQqqJF MIME-Version: 1.0 X-Received: by 10.182.29.33 with SMTP id g1mr4019315obh.59.1391814750048; Fri, 07 Feb 2014 15:12:30 -0800 (PST) Received: by 10.76.20.175 with HTTP; Fri, 7 Feb 2014 15:12:29 -0800 (PST) In-Reply-To: References: Date: Fri, 07 Feb 2014 23:12:00 -0000 Message-ID: Subject: Re: LLVM collaboration? From: Renato Golin To: Jonathan Wakely Cc: "gcc@gcc.gnu.org" Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00101.txt.bz2 On 7 February 2014 22:42, Jonathan Wakely wrote: > The sanitizers are IMHO an impressive example of collaboration. The > process may not be perfect, but the fact is that those powerful tools > are available in both compilers - I think that's amazing! I agree. > Like the Blocks extension? :-) So, as an example, I started a discussion about our internal vectorizer and how we could control it from pragmas to test and report errors. It turned out a lot bigger than I imagined, with people defending inclusion in openMP pragmas, or implementing as C++11 annotations, and even talking about back-porting annotations for C89 code, as an extension. Seriously, that gave me the chills. Working in the ARM debugger, compiler and now with LLVM, I had to work around and understand GNU-isms and the contract that the kernel has with the toolchain, that I don't think is entirely healthy. We should, yes, have a close relationship with them, but some proposals are easier to implement in one compiler than another, others are just implemented because it was the quickest implementation, or generated the smallest code, or whatever. Things that I was expecting to see in closed-source toolchains (as I have), but not on an open source one. At the very least, some discussion could point to defects on one or another toolchain, as well as the kernel. We've seen a fair number of bad code that GCC accepts in the kernel just because it can (VLAIS, nested functions), not because it's sensible, and that's actually making the kernel code worse in respect with the standard. Opinions will vary, and I don't expect everyone to agree with me that those are nasty (nor I want flame from it, please), but some consensus would be good. > I expect that many GCC devs aren't reporting bugs because they're just > not using LLVM. I don't report OpenBSD bugs either, not because I > dislike OpenBSD, I just don't use it. I understand that, and I take your point. I wasn't requesting every one to use it, but to enquire about new extensions when they come your way, as we should do when it comes our way. I'm guilty of this being my first email to the gcc list (and I have been publicly bashed at FOSDEM because of it, which I appreciate). > For things that don't belong in any standard, such as warning options, > that's an area where the compilers may be in competition to provide a > better user-experience, so it's unsurprising that options get added to > one compiler first without discussing it with the other project. What > tends to happen with warnings is someone says "hey, clang has this > warning, we should add it too" e.g. -Wdelete-non-virtual-dtor or > -Winclude-guard, so we may end up agreeing eventually anyway. I think you have touched a very good point: "competition to provide the best user experience". Do we really need that? Front-end warnings are quite easy to replicate, but some other flags may have slightly different semantics on each compiler, and having the user to tell the difference is cruel. Inline assembly magic and new ASM directives are another issue that populate the kernel (and we've been implementing all of them in our assembler to compile the kernel). That simply won't go away ever. I question some of the decisions, as I have questioned some of ARM's decisions on its ABIs, as something that had a purpose, but the core reason is gone, and we can move along. Some consensus would have probably helped to design a better, long-lasting solution, a lot more consensus would have halted any progress, so we have to be careful. But I specifically don't think that extensions required by third-parties (like the kernel) should be discussed directly with any specific compiler, as that will perpetuate this problem. Some kernel developers, including Linus, are very receptive to compiling it with Clang, so new extensions will probably be discussed with both. Now, if we require them to discuss with each community in separate, I'm sure the user experience will be terrible when trying to consolidate it. I don't want us to compete, I want us to collaborate. I don't believe LLVM is ever going to steal GCC's shine, but both will coexist, and having a friendly coexistence would be a lot better for everyone. Aren't we doing open source for a better world? I can't see where competition fits into this. As I said before, one of my main goals of working with LLVM is to make *GCC* better. I believe that having two toolchains is better than one for that very reason, but maintaining two completely separate and competing toolchains is not sustainable, even for open source projects. cheers, --renato