Re: LLVM collaboration?

[Renato Golin <renato.golin@linaro.org>]

On 7 February 2014 22:42, Jonathan Wakely <jwakely.gcc@gmail.com> 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