Re: GCC withdraw

On Aug 29, 2013, at 11:02 AM, David Chisnall wrote:

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

True, but this doesn't cause any problems for gcc, just g++.

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

Fair enough, but the number of these has been, to date, quite small.

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

It actually is close to zero effort. The effort level is quite small, as evidence by the small number of commits to gcc over time. Not zero, but not as huge a deal as you make it out to be.

However, we still need to make the efforts so long as it is part of the base.

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

This is a legitimate issue, for g++, not for gcc. But on !x86 targets we'll need to continue to do this.

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

Seems more like an issue for 11 not 10.

Also, we need to be able to bootstrap the base tools with gcc, since that's been the fallback bootstrap method for some time for people upgrading from really old systems: build the system with clang disabled the first time, and then use that to bootstrap clang since the gcc there can build it. I'd hate to loose this fallback plan, but do recognize at some point we must.

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

Won't this still be an issue for !x86?

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

True, but we're using it now for EABI w/o issue except for doing soft floats. Yes, this is a problem, but we don't have all the infrastructure in place to do hard floating point yet. So absent the required infrastructure to do hard float, this point shouldn't have much weight. What we do on ARM has no bearing on x86 anyway.

So this is more of an interesting side note for future effort that has no bearing at all on the issue at hand.

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

clang generates good code on the ARM, but we still keep hitting issues on the arm with it that go away when gcc is used.  This argument, though is not an argument for why gcc shouldn't be built, but rather why clang should be default. Again, not relevant to the issues at hand. We've had enough problems on arm that we must continue to have gcc easily and readily available.

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

This is total bollox. gcc is intrinsically a cross compiler and has been since 2.0. Our use of it is so limited that you might think that gcc isn't intrinsically a cross compiler.

Also, I often install the base gcc compiler using the 'xdev' targets. This allows me to hack together primitive port cross building support because it installs all the right links for gnu configure based scripts to generally work things out. Again, this is more of a use (freebsd-arm-gcc vs gcc -Bfreebsd-arm) due to how we build gcc. We could, in theory, build all the back ends into our gcc, but we chose a long time ago not to do that.

But this also is not a relevant point to your argument. It is a cool feature that we build clang to include all the other targets, but not relevant to whether to keep gcc in or out of the base system on x86.

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

At the expense of the tree being broken more often, but this will be true whether or not gcc is enabled by default.

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

Also an orthogonal issue.

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

If you are going to do this, then doing it before 10 is best. The stdc++ issue is a compelling one. The base gcc (not g++) is much less so.

Warner