svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib

[David Chisnall]

On 4 Apr 2014, at 14:44, Jordan Hubbard <jkh at ixsystems.com> wrote:

> Ah, OK.  And I’m guessing there’s been no interest in forward-porting the blocks support to 4.7?  That’s kind of…  a bummer.

I don't think so.  Warner has been forward-porting some of the FreeBSD binutils changes, but even Pedro (who did the blocks port to FreeBSD gcc 4.2.1) doesn't want to touch gcc anymore.  

>  I’m guessing the great white hope for all the platforms is a slow convergence on clang then?  What is the compiler toolchain master plan?  If there’s a wiki somewhere describing it, I’d also be happy to just go read that.

Not really.  Converging on clang is nice, but even then it's good to have (at least) a second working compiler for several reasons:

- As we discovered with gcc, having a single source for a core component is usually not ideal, as they can change the rules suddenly

- If there's a bug in clang (and, given that it's getting on for a million lines of C++ code now, the odds are good that there are always going to be a few), it's helpful to have another compiler for testing.

- Periodic testing with another compiler stops us shipping code that relies on non-conformant behaviour.  The amount of effort that it's required to get the Linux kernel to build with clang should be a warning for us - we don't want to fall into the same trap.

That said, I think we're increasingly going to be using LLVM for things that are beyond just simple AOT compilation, so platforms with no LLVM back end are likely to be left behind.

>> For embedded uses, we'd also like to build FreeBSD with vendor's-ugly-hacked-up-gcc-of-the-week.  This is less of an issue now for ARM, but MIPS vendors still hack up gcc in such a way that there's no way that they can get their changes upstreamed and then ship the result with their chips.
> 
> I see.  That’s pretty ugly indeed - is there a list of FreeBSD MIPS folks doing this somewhere?  I ask out of curiosity to know if there’s any collective attempt to chain them all together and insist that they improve clang/MIPS to the point where they can stop doing ugly-ass gcc ports. :)

I'm working with the MIPS people (who are now Imagination Technologies people) to get my MIPS improvements upstreamed.  You can see quite a few of them in the commit log over the past week or two:

http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/Mips/?view=log

Since we also have a hacked-up LLVM that adds support for a custom MIPS chip, I'm also looking at improving the general infrastructure in the MIPS back end, so that we can minimise diffs and make it easy for vendors to push their custom code upstream to LLVM without breaking everyone else.  Or, at the very least, make it cheaper to ship a hacked-up LLVM toolchain than a hacked-up GCC toolchain...

The MIPS people are working hard to get Linux/MIPS building with Clang, so there's a good chance that they'll convince their downstream people to go with it.  I imagine that they're in more or less the same situation as ARM, which can divide their customers nearly into two categories:

- Those that won't touch gcc over the license
- Those that don't care what their compiler is as long as it works

ARM has noticed that LLVM makes both of these groups happy (and is actually using it as the basis for their proprietary compiler as well now).  Hopefully MIPS will too...

David