Date: Fri, 30 Aug 2013 16:11:08 +0100 From: David Chisnall <theraven@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: "Sam Fourman Jr." <sfourman@gmail.com>, toolchain@FreeBSD.org, Boris Samorodov <bsam@passap.ru>, FreeBSD Current <current@FreeBSD.org> Subject: Re: GCC withdraw Message-ID: <54499653-7356-492E-A435-6CC766C90508@FreeBSD.org> In-Reply-To: <201308301041.18874.jhb@freebsd.org> References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <A981C965-D625-458B-B0AB-171C983AEA42@FreeBSD.org> <201308301041.18874.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30 Aug 2013, at 15:41, John Baldwin <jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54499653-7356-492E-A435-6CC766C90508>