From owner-freebsd-current@FreeBSD.ORG Fri Aug 30 15:11:12 2013 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F0376C01; Fri, 30 Aug 2013 15:11:11 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A268F2BFE; Fri, 30 Aug 2013 15:11:11 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r7UFB816009699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Aug 2013 15:11:10 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: <201308301041.18874.jhb@freebsd.org> Date: Fri, 30 Aug 2013 16:11:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <201308301041.18874.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1508) Cc: "Sam Fourman Jr." , toolchain@FreeBSD.org, Boris Samorodov , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 15:11:12 -0000 On 30 Aug 2013, at 15:41, John Baldwin wrote: > So my take away from this is that you have no plans to support any = platform that > doesn't support clang as you just expect ia64 and sparc64 to die and = not be > present in 11.0. That may be the best path, but I've certainly not = seen that > goal discussed publically. I expect that platforms that don't have support from clang or some = external toolchain will die. If people care about IA64, then getting = Intel's compiler working as an external toolchain would probably be a = good idea (it generates vastly better code than gcc). If people care = about SPARC64, then either gcc from ports as an external toolchain, or = finishing up the SPARC64 back end in LLVM are options. Finishing the = SPARC64 back end is not that much effort (it's probably a couple of = person-months of work - getting the calling conventions right does = require some small tweaks to LLVM IR that I think someone's working on), = but it hasn't been done because no one appears to care quite enough to = make it a priority. >>> Don't get me wrong, I don't love GCC per se, and on my laptop I've = hacked >>> the relevant ports so that everything is built with clang. I would = also >>> love to be able to build the base system with GCC 47 instead of 42, = it just >>> doesn't seem that we are there yet. >>=20 >> The time to raise objections for this was when the plan was = originally raised over a year ago, or at any of the points when it's = been discussed in=20 > between. It is not after we're ready to flip the switch. >=20 > So I think the crux of the issue might be this: >=20 > I have no doubt that this has been discussed extensively on toolchain@ = and in > toolchain-specific devsummit sessions. The proposal to disable GCC by = default > does not appear to have been discussed in a wider audience from what I = can > tell. (I can't find any relevant threads on arch@ or current@ prior = to this > one.) While this is a toolchain-specific decision, it is a very broad > decision. Also, we aren't here because of a new thread started = intentionally > to say "Hey, we as the toolchain folks think we should disable GCC by = default > on 10 for x86". Instead, we started off in a thread about adding AES > instructions to our binutils and out of left field there is an e-mail = of > "Oh, don't bother cause I'm disabling GCC next week" (paraphrase). = Can you > appreciate at all that this is a total surprise to people who aren't > subscribed to toolchain@ and haven't been to a toolchain session at a=20= > devsummit and that this looks like a drive-by change? Yes, we certainly could have communicated this better. I was under the = impression that this was widespread common knowledge and something I've = personally discussed with various people including ports people on = several occasions. I would have made the commit a couple of months ago, = but getting the ports infrastructure back up to a state where it's easy = to test has been a blocker there. =20 If removing gcc from the standard install is going to cause major pain = for people, then we can leave it in for 10.0. I'm currently doing a = make tinderbox on the removal patch, modified to leave gcc in, and only = remove libstdc++, which is something that we definitely need to do = because it's causing an amount of pain that is only going to increase. = I have no plans to make anything in the base system (other than clang = itself, when 3.4 is imported) depend on libc++-only features (I'd love = to do it for dtc, but it has to run on embedded platforms that are going = to be stuck with libstdc++ in base for a while - at least a year, and = that's if we're lucky). =20 Anyway, Ian has reminded me that I'm getting stuck in sidetracks, so = here's an executive summary of what I'm ACTUALLY proposing: - On platforms where clang is cc, don't build libstdc++, make libc++ the = default. Provide libstdc++ from base as a 9-compat package. - On platforms where clang is cc, don't build gcc by default (I've = already agreed not to commit this part, since it seems very = controversial, although I'd like to better understand why it is so) - On platforms where clang is cc, allow building libstdc++ by setting = the WITH_GNUCXX flag - On platforms where clang is cc, allow building gcc by setting the = WITH_GCCflag - On platforms where clang is not cc, leave gcc as the default system = compiler - On platforms where clang is not cc, leave libstdc++ as the default = system STL, but encourage ports to start depending explicitly on = ports-libstdc++ so that they don't suffer from ABI mismatch issues. If your workflow depends on gcc on a clang-is-cc platform, then you are = free to install it. If your workflow depends on libstdc++ on a clang-is-cc platform, then = you are free to install it, clang will still use it if you specify = -stdlib=3Dlibstdc++. If your workflow depends on gcc or libstdc++ on any other platform, you = will see no difference. If you need to test whether building the base system or kernel with gcc = fixes things that are broken, then you are free to build = WITHOUT_CLANG_IS_CC and WITH_GCC and test it (or set WITH_GCC, install, = and then use XCC to use the installed gcc for testing. Or install one = of the lang/gcc ports and use XCC for testing). In the medium term, = this should continue to work until there is some compelling reason for = it to be broken (which is the topic of a future discussion, where I = would expect very compelling reasons to be required). =20 I am not proposing: - To delete gcc from the tree - To delete libstdc++ from the tree - To deprecate any architectures - To break any architectures - To commit loads of C++11 / C11 code to the base system and break the = build with gcc - To rely on any clang-specific extensions in base-system code - To remove anything from cdefs.h that allows stuff to work with gcc - To set fire to your cat David