Re: GCC withdraw

On 30 Aug 2013, at 15:41, John Baldwin <jhb_at_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.
>> 
>> 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 
> between.  It is not after we're ready to flip the switch.
> 
> So I think the crux of the issue might be this:
> 
> I have no doubt that this has been discussed extensively on toolchain_at_ 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_at_ or current_at_ 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_at_ and haven't been to a toolchain session at a 
> 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.  

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

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=libstdc++.
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).  

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