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

Warner Losh imp at
Fri Apr 4 16:27:52 UTC 2014

On Apr 4, 2014, at 8:03 AM, David Chisnall <theraven at> wrote:

> On 4 Apr 2014, at 14:44, Jordan Hubbard <jkh at> 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.  

As far as I can tell, all the binutils stuff is upstream. It’s the gcc hacks that we’ve done that I’m working on.

>> 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.

I image there will be a slow rollout of the LLVM features, where they replace current features to make them faster, the non-clang platforms get less optimal performance. For new features, the non-clang platforms might get reduced functionality in that area. I doubt that we’ll have any core, mandatory feature requiring LLVM for some time, though that day may come… I doubt it will be a sudden switch.

In the mean time, things like gcc x86 kernel builds start to decay… They are broken right now…


More information about the svn-src-head mailing list