From owner-svn-src-all@FreeBSD.ORG Fri Apr 4 14:04:06 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FE51213; Fri, 4 Apr 2014 14:04:06 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "theravensnest.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 70F30236; Fri, 4 Apr 2014 14:04:04 +0000 (UTC) Received: from [192.168.0.100] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.7) with ESMTP id s34E3rLl073427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Apr 2014 14:03:55 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib From: David Chisnall In-Reply-To: Date: Fri, 4 Apr 2014 15:03:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8E3BD3C1-A441-48C5-97BC-45EF67513096@FreeBSD.org> References: <201404021607.s32G7mhw051355@svn.freebsd.org> <20140404115256.GA85137@ivaldir.etoilebsd.net> <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> To: Jordan Hubbard X-Mailer: Apple Mail (2.1874) Cc: svn-src-head@freebsd.org, Baptiste Daroussin , src-committers@freebsd.org, svn-src-all@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 14:04:06 -0000 On 4 Apr 2014, at 14:44, Jordan Hubbard 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