Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Apr 2014 15:03:49 +0100
From:      David Chisnall <theraven@FreeBSD.org>
To:        Jordan Hubbard <jkh@ixsystems.com>
Cc:        svn-src-head@freebsd.org, Baptiste Daroussin <bapt@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org
Subject:   Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
Message-ID:  <8E3BD3C1-A441-48C5-97BC-45EF67513096@FreeBSD.org>
In-Reply-To: <B06E1588-8828-485F-A407-3F19231F8EA5@ixsystems.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Apr 2014, at 14:44, Jordan Hubbard <jkh@ixsystems.com> wrote:

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

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

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

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.
>=20
> I see.  That=92s pretty ugly indeed - is there a list of FreeBSD MIPS =
folks doing this somewhere?  I ask out of curiosity to know if there=92s =
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=3Dlog=


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8E3BD3C1-A441-48C5-97BC-45EF67513096>