Date: Thu, 29 Aug 2013 18:02:06 +0100 From: David Chisnall <theraven@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: "Sam Fourman Jr." <sfourman@gmail.com>, toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" <freebsd-current@FreeBSD.org>, Boris Samorodov <bsam@passap.ru>, FreeBSD Current <current@FreeBSD.org> Subject: Re: GCC withdraw Message-ID: <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> In-Reply-To: <201308291057.43027.jhb@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_978AE49C-F592-44BA-A78D-AD85AE5E0E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 Aug 2013, at 15:57, John Baldwin <jhb@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). =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 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. =20 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. =20 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. =20 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 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 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 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. =20 David --Apple-Mail=_978AE49C-F592-44BA-A78D-AD85AE5E0E9A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSH36PAAoJEKx65DEEsqIdb7YQAJoGYPQdMLAPwhHHrLa3Rvl5 efXPgzzMs5vgVjLi3xd3PFy7jDJVeG9SoGOc+BhnC5mWM12aa6vtP21krogCHlkt O59ApLiPE0orcLcNQYgdqxGZmoKCGRHYrGtCd6Ztvp3pKfcgwmXPJ47VPRjntIDN TvFNNEO2GnKiHUpOZZVw5g6kYcQT6lz9gigjNzW2k/662T0quoiJSGwNW6wsf9Is NQDSxGh4SVPGrtAvShY6FW31a0iWyAn42q7TmIA9tgjQIiLVFn3MG4ijWDp2YDXV dIJe6SaC+YmRy5Y2ajf9lraKRB3eZaquUhT2VzWvTx3hbDh5ng+Wat81UuEC04KI 1srCjkkHRgV+U7PPD+sjz9FUxXdpaevpcn35WepOsKqF2M/j31tg1qeB+oIaovPM SDEgaR50QR9o/LKKFaqSJMnyyzIRdFRK8SiWz8BPFrrWPW79MS5jtH12Nd6nSAcq kIiyqYSMm0ZuuAiPSsVUEY1q0Dd3snajlT5dWrCl7bdSawV26uk/15lGDRiYo9I0 xsZ0oVQn4itkCQ9DS25OwdAR5w5gRy/tmnmIOm1C8YEUBfb+4BHq1YZlmLfAlkBz lvChjb41fnHKcjgJ3nGzk4+BoHelEc46Ggnc9uqMEF2muboeFPazm2gBbc/sAODm bFuhOfRbt4PHMXMNKv+r =zkC2 -----END PGP SIGNATURE----- --Apple-Mail=_978AE49C-F592-44BA-A78D-AD85AE5E0E9A--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8F836479-BC3A-4679-A7AA-3BCDD34AE6C5>