From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3221 invoked by alias); 13 Sep 2010 22:06:10 -0000 Received: (qmail 3213 invoked by uid 22791); 13 Sep 2010 22:06:09 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Sep 2010 22:05:55 +0000 Received: from eggs.gnu.org ([140.186.70.92]:56457) by fencepost.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvHA5-00041E-Va for gcc@gnu.org; Mon, 13 Sep 2010 18:06:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OvH9r-00056g-Ik for gcc@gnu.org; Mon, 13 Sep 2010 18:05:52 -0400 Received: from mail-bw0-f41.google.com ([209.85.214.41]:39946) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvH9r-00056S-C7; Mon, 13 Sep 2010 18:05:51 -0400 Received: by bwz6 with SMTP id 6so6193754bwz.0 for ; Mon, 13 Sep 2010 15:05:50 -0700 (PDT) Received: by 10.204.82.155 with SMTP id b27mr3571019bkl.182.1284415550237; Mon, 13 Sep 2010 15:05:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.141.144 with HTTP; Mon, 13 Sep 2010 15:05:30 -0700 (PDT) In-Reply-To: References: <11009101222.AA29048@vlsi1.ultra.nyu.edu> <11009101240.AA29231@vlsi1.ultra.nyu.edu> <4C8DFD2E.5070406@gnu.org> <20100913145516.GA1156@bromo.med.uc.edu> From: =?ISO-8859-1?Q?Manuel_L=F3pez=2DIb=E1=F1ez?= Date: Tue, 14 Sep 2010 10:13:00 -0000 Message-ID: Subject: Re: Merging Apple's Objective-C 2.0 compiler changes To: Ian Lance Taylor Cc: Jack Howarth , Paolo Bonzini , Steven Bosscher , Richard Kenner , Joe.Buck@synopsys.com, clattner@apple.com, dave.korn.cygwin@gmail.com, gcc@gnu.org, mikestump@comcast.net, nicola.pero@meta-innovation.com, richard.guenther@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-IsSubscribed: yes 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 X-SW-Source: 2010-09/txt/msg00265.txt.bz2 On 13 September 2010 23:41, Ian Lance Taylor wrote: > Manuel L=F3pez-Ib=E1=F1ez writes: > >> On 13 September 2010 22:04, Ian Lance Taylor wrote: >>> Manuel L=F3pez-Ib=E1=F1ez writes: >>> >>>> From a user-perspective, there are benefits on both clang->gcc and >>>> gcc->llvm. However, from what I know about the GCC project, I don't >>>> see yet how GCC developers can consider either more beneficial than >>>> the other. >>> >>> It seems to me that at the present moment LLVM's frontends are better >>> than GCC's, and GCC's backends are better than LLVM's. =A0By this I mean >>> specifically that LLVM's frontends generate better diagnostics, whereas >>> GCC's backends generate code that has better runtime performance. =A0(L= LVM >>> also appears to run faster, which is a good feature but not in my mind a >>> determining one.) =A0Therefore, I see a clear benefit to clang->gcc, bu= t I >>> do not see a clear benefit to gcc->llvm. =A0This comment is of course >>> entirely independent of the licensing issues. >> >> I think you are again talking about user benefits. > > I'm not sure I understand the distinction you are drawing. =A0What is the > difference between a benefit to users of gcc and a benefit to gcc > itself? > >> You don't see a >> (user) benefit in gcc->llvm because you perhaps do not use the >> features that LLVM has and GCC doesn't. But users of gcc->llvm surely >> see a large benefit if people have spent so much effort working on it, >> first as a patched gcc and now as a plugin. > > I understand the benefit that existed before clang. =A0And my general > understanding is that clang C++ support is not yet complete, so there is > a benefit there, but only a temporary one. =A0I don't see a real benefit > going forward. Access to all the other GCC front-ends that the LLVM project has not (yet) reimplemented? Someone provided above a real user-case for gcc->llvm involving Fortran. I don't think dragon-egg development is stalled at all. >> But I am talking about benefits to GCC. Do you see any >> benefit/downside on adding code to GCC to enable a plugin that >> implements clang->gcc? > > Since for me benefits to users of gcc are pretty much the same as > benefits to gcc, yes, I see a benefit. By that rule, it is clearly beneficial for some gcc users to compile Fortran using dragon-egg to take advantage of OpenCL. Ergo, dragon-egg is beneficial to GCC. Anyway, I don't see anyone implementing clang->gcc soon, but it is good to know it would be welcome. Thanks for answering, Manuel.