From owner-freebsd-current@FreeBSD.ORG Thu Aug 29 17:22:04 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DF1B3AFC for ; Thu, 29 Aug 2013 17:22:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A220E29DE for ; Thu, 29 Aug 2013 17:22:03 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id eh20so798579obb.1 for ; Thu, 29 Aug 2013 10:22:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=T1iQD6QrxM9x42tWOEQg+Q8k8Bb52BHKR7Ia+HQYb9I=; b=LNktS+BVGuQLubpjB/mCyBbD1oZ4bmvT06FudErfKEmYc6sap6HOmvFTpFRl8yuL7O ztt5CD9m5EAOMBIzoMvHVC+0vY32fx8czscwqRUy26tf0ucFqywjsjNCjpMrNpbbEhtr IJMF6MDAklwIa9smAPLOENSJaEiNbyiuLhUgHxIrpq6/4PN1JuE0tnxlqbSCGJ6ulXha /xvFysv36MY3R/dd//AOE0dXoWu0NOhnOut4KnD9dFOnRUiFbjxYJOC3ZJ0Rn4+PZv3I rZYs/YnGJDLLDDP3oIfENO81yh1kpDRZIF8CFT8sJ9GpjXavv1BR+uQwGgZbjRvq1Va9 QWWA== X-Gm-Message-State: ALoCoQnhdJB8C/MC1yYmvAkL33QPH7u5u6/GCTaClDePwQ5mDGs0o+D6HguqTAXq9xg4lu+k3nwU X-Received: by 10.60.51.7 with SMTP id g7mr3468744oeo.6.1377796922709; Thu, 29 Aug 2013 10:22:02 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id z5sm32455135obg.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 10:22:01 -0700 (PDT) Sender: Warner Losh Subject: Re: GCC withdraw Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> Date: Thu, 29 Aug 2013 11:21:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0678F678-A140-4A69-AF46-EA1C036DAA1A@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.1085) Cc: FreeBSD Current , toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" , "Sam Fourman Jr." , Boris Samorodov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 17:22:04 -0000 On Aug 29, 2013, at 11:02 AM, David Chisnall wrote: > On 29 Aug 2013, at 15:57, John Baldwin 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=