Re: GCC withdraw

On 29 Aug 2013, at 15:57, John Baldwin <jhb_at_freebsd.org> wrote:

>   I have not seen any convincing
> argument as to why leaving GCC in the base for 10.x impedes anything.
> Because clang isn't sufficient for so many non-x86 platforms we can't
> really start using clang-specific features yet anyway.

Apparently I haven't been good at communicating, so I'll try to here.  I apologise for ignoring this thread for the last week: I've been rather busy organising the DevSummit.  The notes for the sessions will be posted to various mailing lists soon (and summarised for a special status report), but since the ports and toolchain build sessions are already largely up you can check these on the wiki.  You'll notice that in both sessions the topic of removing gcc / libstdc++ was raised and there was no objection (not sure if it's in the notes, but there was a lot of support during the ports session from people who didn't want the pain of maintaining compatibility with gcc-in-base, and especially with g++/libstdc++ in base).  

This is not a new plan, it is the plan that has been on the wiki and discussed at at least two DevSummits that I have attended before this week and probably others that I missed, as well as on various mailing lists and in IRC.  

To summarise the current issues:

Our libstdc++ is ancient.  It supports C++98 well, it kind-of supports C++03.  It doesn't support C++11 at all and never will, nor does it support C++14.  An increasing number of ports are depending on C++11, because it provides much cleaner syntax than C++98 and so these are being forced to depend on gcc46 or gcc47 to build.  Unfortunately, libstdc++ in ports is not ABI compatible with the libstdc++ that we ship, which causes library ABI versions.  This problem will only get worse over the coming years.  An increasing number of these ports do build with libc++ (since it's the only option on OS X / iOS - most do already and most of the fixes needed are just adding some inclusions since libc++ doesn't leak C headers as much as libstdc++), so defaulting to libc++ will reduce these problems over time.  

Maintaining our libstdc++ is not a zero-effort operation.  We have to modify it whenever libc gains new features (e.g. POSIX2008 locales, new libm functions) and this requires developer time tracking down the new bugs (because the static configuration files no longer match the included headers) and fixing them.

Maintaining out gcc is also not a zero-effort operation.  Even though it is not the default compiler for amd64 or i386, we still have to add support for new instructions to them, even if we only want to use them in machine-dependent code on these architecture.  

Our g++ in base can only work with libstdc++, not libc++.  This means that shipping gcc in 10.0 in base means that we'd be shipping two C++ compilers, which preferred different standard libraries, with incompatible ABIs.  This is setting us up for a world of pain.

When we enable LLDB during the 10.x timeframe (emaste has been working hard, but it's probably not quite ready for 10.0), it will have to link against both LLVM libraries and libc++ (as it uses C++11 and doesn't work with our libc++).  This is a minor issue, as the only requirement here is that we switch to linking LLVM against libc++ instead of libstdc++, but it is an example of one more piece of code that won't build with our gcc that is in the base system (not yet enabled by default).  Clang 3.4 will not build with our gcc either (which will cause some bootstrapping problems that we'll have to address for people going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as long as we tweak the build system to use clang and not cc for the bootstrap build).

Lots of configure scripts will use gcc in preference to cc (or g++ in preference to c++) if they find them in the same place.  Many of these no longer work with our old gcc, but do work with clang, adding more effort to ports.  According to the test runs that bapt did at the DevSummit this week, we have more ports failing on 10 with gcc than on 10 with gcc removed.

Our gcc does not support the ARM EABI hard float variant.  I misspoke earlier when I thought it didn't support EABI at all, but it turns out that it's only the case for hard-float.  This is the ABI that we want to be using on pretty much all ARMv6 and newer systems, because a lot of ARM cores (such as the Cortex A8 in the Efika MX that the Foundation has paid for FreeBSD to be ported on to use as a demo ARM device) require a complete pipeline flush when moving between integer and floating point registers and the soft-float variant of the ABI puts all arguments in integer registers.  This means that a simple function that takes a rectangle (4 floating point values) as an argument will require 8 pipeline flushes to call, which various Linux distributions have found is crippling for graphical applications.  

We want to start shipping binary packages for ARMv6.  At the moment, i386, amd64, and ARMv6 are the only architectures where you can get cheap, off-the-shelf, hardware that looks enough like a normal computer that you'd expect to be able to use a stock install, and so they are the only platforms where the default build configuration makes a difference.  For all of these preferences, clang is the default and there is no reason to prefer our gcc: if you actually want to use gcc (e.g. if you care about the C99 floating point craziness, or you have OpenMP code to build) then one of the gcc versions in ports will give you much better code (and better error reporting).  

Unlike clang, gcc is not intrinsically a cross compiler.  This means that if you are targeting a non-x86, non-ARM architecture then you are already building a cross-gcc to use as part of your bootstrap process and so not having the x86-only gcc on your host system does not cost you anything.  As someone who spends day-job time working on FreeBSD/MIPS, I've never found the need to use the installed base-gcc (my life would be much happier if we had some nice infrastructure for building packages of the MIPS toolchain, headers, and shared libraries, but that's an unrelated issue).  

The tinderboxes will prevent any gcc-incompatible code from appearing in the MI bits of the kernel.  Optional parts of the userland can slowly migrate to supporting newer language features.  

Last but not quite least, people keep complaining about ever-increasing build times and the size of the base system.  Building a gcc and libstdc++ by default every time, that we're telling people not to use, won't help with that...

I have not heard any compelling arguments for keeping gcc and libstdc++ as part of the default install on x86, and I have listed a number of reasons why doing so creates extra work for people who maintain the toolchain and who work on ports.  I intend to commit the change to remove both from the default build and make libc++ the default STL for clang++ as soon as I get an okay from bapt.  

David