Date: Thu, 29 Aug 2013 11:21:59 -0600 From: Warner Losh <imp@bsdimp.com> To: David Chisnall <theraven@FreeBSD.org> Cc: FreeBSD Current <current@FreeBSD.org>, toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" <freebsd-current@FreeBSD.org>, "Sam Fourman Jr." <sfourman@gmail.com>, Boris Samorodov <bsam@passap.ru> Subject: Re: GCC withdraw Message-ID: <0678F678-A140-4A69-AF46-EA1C036DAA1A@bsdimp.com> In-Reply-To: <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <CAOFF%2BZ3vbOgMO7T-BKZnhKte6=rFoGcdYcft5kpAgNH2my1JKg@mail.gmail.com> <DC41B4BD-159A-408B-804A-0230F3E0E52B@FreeBSD.org> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 29, 2013, at 11:02 AM, David Chisnall wrote: > On 29 Aug 2013, at 15:57, John Baldwin <jhb@freebsd.org> wrote: >=20 >> 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. >=20 > 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). =20 >=20 > 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. =20 >=20 > To summarise the current issues: >=20 > 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. =20 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. =20 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. =20 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). =20 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). =20 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. =20 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. =20 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0678F678-A140-4A69-AF46-EA1C036DAA1A>