Re: GCC withdraw

On 1 Sep 2013, at 02:53, Benjamin Kaduk <kaduk_at_MIT.EDU> wrote:

> I am worried about the definition of "polished".  I held my tongue in Ottawa in 2011 when Kirk wanted to turn SU+J on by default, since I figured he knew what was going on much better than I did.  Then, we discovered the bad interactions between SU+J and snapshots.  If memory serves, things like sparc64 and mips64 support for clang/llvm and XCC suppor are being described as only "a few man-months work away".  But that seems to be just to get something which is working ... I fear that to get it truly "polished" will be another 2-3 years on top of those man-months. If we are in agreement about what "polished" means, then by all means announce with 10.0 that gcc's days are numbered and drop it at the appropriate 10.x.  I just don't want us to discover terrible bugs a few months after we make a switch, due to being wrong about "polished".

We are using XCC to build FreeBSD today, on x86 with experimental tools and on MIPS with the compiler in base.  It works, but it could do with better documentation.  That's what I mean by polishing: making sure that it doesn't just work, it works and is easy to use.  Part of this will involve ensuring that we have packages for cross compilers for various platforms so that it's really easy to just install a package with the cross toolchain you want and point your already-installed source tree at it to get a cross-build environment.  

Many of us have been running clang-is-cc for a long time and we're now seeing more port build failures on 10-with-gcc than 10-without-gcc.  That's what I mean by polished.

The SPARC back end in LLVM is marked as experimental.  Looking over the code, it's actually in a better state than I thought it would be.  Some people seem to be working on it.  It's not something I would count on getting to a useable state though.  If SPARC is to remain a supported architecture, then we'll probably be using an external toolchain for it, unless someone wants to spend a couple of months chasing bugs in the LLVM SPARC back end.  Oracle seems to be being quite effective at killing SPARC64 as an architecture for running anything other than Oracle appliances, but SPARC32 is still quite popular in aerospace so it may still be an interesting platform in a few years.

David