public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Pinski <pinskia@gmail.com>
To: Diego Novillo <dnovillo@google.com>
Cc: Renato Golin <renato.golin@linaro.org>, gcc <gcc@gcc.gnu.org>
Subject: Re: LLVM collaboration?
Date: Fri, 07 Feb 2014 22:28:00 -0000	[thread overview]
Message-ID: <CA+=Sn1kWoDV5Nmcn_BxJoBFMF03HmF4OPnNvJ0T-7HH1DFXhyA@mail.gmail.com> (raw)
In-Reply-To: <CAD_=9DSZs=H3=GJnkv1VOaNi01FnSM4o7mb_51QwHZgs1BW7LQ@mail.gmail.com>

On Fri, Feb 7, 2014 at 1:53 PM, Diego Novillo <dnovillo@google.com> wrote:
> On Fri, Feb 7, 2014 at 4:33 PM, Renato Golin <renato.golin@linaro.org> wrote:
>
>> I'll be at the GNU Cauldron this year, feel free to come and discuss
>> this and other ideas. I hope to participate more in the GCC side of
>> things, and I wish some of you guys would do the same on our side. And
>> hopefully, in a few years, we'll all be on the same side.
>
> I think this would be worth a BoF, at the very least. Would you be
> willing to propose one? I just need an abstract to get it in the
> system. We still have some room left for presentations.

I still don't see any need for this extra BoF really.  They should be
handled at the sources of the extensions rather than the destination
of the extensions.  In fact I see this as weaking the computition
between the two compilers.  Things like the new attributes being added
for the kernel to use (in fact they are already implemented in sparse
is a thing which should be mentioned here) should have been talked
about the source.  HPA filed the bugs to GCC as he is an user of GCC
but not an user of LLVM, if someone in the kernel community wanted
LLVM support they would have filed the bugs there.

And then again the original message here is that GCC is not
controlling binutils (ld) and " ld should not accept this deprecated
instruction, but we
can't change that"  but you should have talked with the binutils
community rather than the GCC one since they are two separate projects
(though most folks work on both).

Thanks,
Andrew Pinski

>
> I think the friendly competition we have going between the two
> compilers has done nothing but improve both toolchains. I agree that
> we should keep it at this level. Any kind of abrasive interaction
> between the two communities is a waste of everyone's time.
>
> Both compilers have a lot to learn from each other.
>
>
> Diego.

  parent reply	other threads:[~2014-02-07 22:28 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAMSE1kdfpeLp6NEc+jnEWqi0KWV-+=Q701UsiLhgcn13X6fYcA@mail.gmail.com>
2014-02-07 21:34 ` Fwd: " Renato Golin
2014-02-07 21:53   ` Diego Novillo
2014-02-07 22:07     ` Renato Golin
2014-02-07 22:33       ` Andrew Pinski
2014-02-07 22:35         ` Renato Golin
2014-02-10 14:48       ` Diego Novillo
2014-02-07 22:28     ` Andrew Pinski [this message]
2014-02-07 22:23   ` Andrew Pinski
2014-02-07 22:42   ` Jonathan Wakely
2014-02-07 23:12     ` Renato Golin
2014-02-07 23:30   ` Fwd: " Joseph S. Myers
2014-02-07 23:59     ` Renato Golin
2014-02-11  2:29   ` Jan Hubicka
2014-02-11  9:55     ` Renato Golin
2014-02-11 10:03       ` Uday Khedker
2014-02-11 16:00         ` Jan Hubicka
2014-02-11 16:07           ` Uday Khedker
2014-02-11 16:18           ` Renato Golin
2014-02-11 17:29       ` Renato Golin
2014-02-11 18:02         ` Rafael Espíndola
2014-02-11 18:51           ` Markus Trippelsdorf
2014-02-11 20:52             ` Jan Hubicka
2014-02-11 21:20           ` Jan Hubicka
2014-02-11 21:38             ` Rafael Espíndola
2014-02-11 22:36               ` Hal Finkel
2014-09-17 21:41                 ` Hal Finkel
2014-02-12 11:10             ` Fwd: " Richard Biener
2014-02-12 13:15               ` Rafael Espíndola
2014-02-12 16:19               ` Joseph S. Myers
2014-02-12 16:23                 ` Jan Hubicka
2014-02-13  9:06                   ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+=Sn1kWoDV5Nmcn_BxJoBFMF03HmF4OPnNvJ0T-7HH1DFXhyA@mail.gmail.com' \
    --to=pinskia@gmail.com \
    --cc=dnovillo@google.com \
    --cc=gcc@gcc.gnu.org \
    --cc=renato.golin@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).