From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9775 invoked by alias); 7 Feb 2014 22:42:40 -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 9764 invoked by uid 89); 7 Feb 2014 22:42:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f176.google.com Received: from mail-lb0-f176.google.com (HELO mail-lb0-f176.google.com) (209.85.217.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 07 Feb 2014 22:42:39 +0000 Received: by mail-lb0-f176.google.com with SMTP id w7so3109561lbi.7 for ; Fri, 07 Feb 2014 14:42:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.201.164 with SMTP id kb4mr10995202lbc.32.1391812955486; Fri, 07 Feb 2014 14:42:35 -0800 (PST) Received: by 10.112.143.70 with HTTP; Fri, 7 Feb 2014 14:42:35 -0800 (PST) In-Reply-To: References: Date: Fri, 07 Feb 2014 22:42:00 -0000 Message-ID: Subject: Re: LLVM collaboration? From: Jonathan Wakely To: Renato Golin Cc: "gcc@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00100.txt.bz2 On 7 February 2014 21:33, Renato Golin wrote: > > Worst still, with Clang and LLVM getting more traction recently, and > with a lot of very interesting academic work being done, a lot of new > things are getting into LLVM first (like the sanitizers, or some > specialized pragmas) and we're dangerously close to start having > clang-extensions, which in my humble opinion, would be a nightmare. 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! > We, on the other side of the fence, know very well how hard it is to > keep with legacy undocumented gcc-extensions, and the ARM side is > particularly filled with magical things, so I know very well how you > guys would feel if you, one day, had to start implementing clang stuff > without even participating in the original design just because someone > relies on it. Like the Blocks extension? :-) > So, as far as I can see (please, correct me if I'm wrong), there are > two critical problems that we're facing right now: > > 1. There IS an unnecessary fence between GCC and LLVM. > > License arguments are one reason why we can't share code as easily as > we would like, but there is no argument against sharing ideas, > cross-reporting bugs, helping each other implement a better > compiler/linker/assembler/libraries just because of an artificial > wall. We need to break this wall. If there's a wall I agree we should break it (I don't see one in the areas I work on, which I think is great). > I rarely see GCC folks reporting bugs on our side, For my part, I report them when I find them, but I just don't use Clang or LLVM that much, so I don't find many (also the few things I test often work correctly anyway!) 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 happen to have a very deep respect for GCC *and* for my preferred > personal license (GPLv3), but I also happen to work with LLVM, and I > like it a lot. There is no contradiction on those statements, and I > wish more people could share my opinion. I'm sure many of us do. IMHO more collaboration should help both projects, but I think there is already more collaboration than some people realise. Development of OpenMP, DWARF, the C++ Itanium ABI, the psABI etc. happens in the open and is not limited to GNU devs. 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.