Date: Fri, 4 Apr 2014 10:27:44 -0600 From: Warner Losh <imp@bsdimp.com> To: David Chisnall <theraven@FreeBSD.org> Cc: svn-src-head@freebsd.org, Baptiste Daroussin <bapt@FreeBSD.org>, src-committers@freebsd.org, Jordan Hubbard <jkh@ixsystems.com>, svn-src-all@freebsd.org Subject: Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib Message-ID: <9E916835-C870-4F7E-B594-EB4671C404B2@gmail.com> In-Reply-To: <8E3BD3C1-A441-48C5-97BC-45EF67513096@FreeBSD.org> References: <201404021607.s32G7mhw051355@svn.freebsd.org> <20140404115256.GA85137@ivaldir.etoilebsd.net> <F2A33EA8-14F2-4D62-9021-9023A1751E48@FreeBSD.org> <8D6AF193-A5A3-4A28-A230-97A543395ACA@ixsystems.com> <2E0EC8CB-B3EE-4DB8-A33D-58FD2107F14D@FreeBSD.org> <6A02504F-5543-4F91-92F6-7B4FB9A34DC4@ixsystems.com> <152D73EE-DF9E-4757-B547-F1F22B12C824@FreeBSD.org> <B06E1588-8828-485F-A407-3F19231F8EA5@ixsystems.com> <8E3BD3C1-A441-48C5-97BC-45EF67513096@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 4, 2014, at 8:03 AM, David Chisnall <theraven@FreeBSD.org> wrote: > On 4 Apr 2014, at 14:44, Jordan Hubbard <jkh@ixsystems.com> wrote: >=20 >> Ah, OK. And I=92m guessing there=92s been no interest in = forward-porting the blocks support to 4.7? That=92s kind of=85 a = bummer. >=20 > 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. =20 As far as I can tell, all the binutils stuff is upstream. It=92s the gcc = hacks that we=92ve done that I=92m working on. >> I=92m 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=92s a wiki somewhere describing it, I=92d also be happy to just = go read that. >=20 > Not really. Converging on clang is nice, but even then it's good to = have (at least) a second working compiler for several reasons: >=20 > - As we discovered with gcc, having a single source for a core = component is usually not ideal, as they can change the rules suddenly >=20 > - 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. >=20 > - 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. >=20 > 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=92ll have = any core, mandatory feature requiring LLVM for some time, though that = day may come=85 I doubt it will be a sudden switch. In the mean time, things like gcc x86 kernel builds start to decay=85 = They are broken right now=85 Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9E916835-C870-4F7E-B594-EB4671C404B2>