From owner-freebsd-current@FreeBSD.ORG Sun Sep 1 07:58:51 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 B9D265B6; Sun, 1 Sep 2013 07:58:51 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B9672C63; Sun, 1 Sep 2013 07:58:50 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r817wgLI027898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Sep 2013 07:58:43 GMT (envelope-from theraven@freebsd.org) Content-Type: multipart/signed; boundary="Apple-Mail=_44BBE6AB-A070-4794-A716-1A9712C2128B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: GCC withdraw From: David Chisnall In-Reply-To: Date: Sun, 1 Sep 2013 08:58:36 +0100 Message-Id: <1DB38CEA-6821-4206-8F5A-24EDF1483223@freebsd.org> References: <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <201308301041.18874.jhb@freebsd.org> <20130831073330.GC36239@funkthat.com> <98D31DD3-8A1D-46ED-9BF6-9EBE39640860@freebsd.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.1508) Cc: toolchain@freebsd.org, FreeBSD Current 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: Sun, 01 Sep 2013 07:58:51 -0000 --Apple-Mail=_44BBE6AB-A070-4794-A716-1A9712C2128B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 1 Sep 2013, at 02:53, Benjamin Kaduk wrote: > I am worried about the definition of "polished". I held my tongue in = Ottawa in 2011 when Kirk wanted to turn SU+J on by default, since I = figured he knew what was going on much better than I did. Then, we = discovered the bad interactions between SU+J and snapshots. If memory = serves, things like sparc64 and mips64 support for clang/llvm and XCC = suppor are being described as only "a few man-months work away". But = that seems to be just to get something which is working ... I fear that = to get it truly "polished" will be another 2-3 years on top of those = man-months. If we are in agreement about what "polished" means, then by = all means announce with 10.0 that gcc's days are numbered and drop it at = the appropriate 10.x. I just don't want us to discover terrible bugs a = few months after we make a switch, due to being wrong about "polished". We are using XCC to build FreeBSD today, on x86 with experimental tools = and on MIPS with the compiler in base. It works, but it could do with = better documentation. That's what I mean by polishing: making sure that = it doesn't just work, it works and is easy to use. Part of this will = involve ensuring that we have packages for cross compilers for various = platforms so that it's really easy to just install a package with the = cross toolchain you want and point your already-installed source tree at = it to get a cross-build environment. =20 Many of us have been running clang-is-cc for a long time and we're now = seeing more port build failures on 10-with-gcc than 10-without-gcc. = That's what I mean by polished. The SPARC back end in LLVM is marked as experimental. Looking over the = code, it's actually in a better state than I thought it would be. Some = people seem to be working on it. It's not something I would count on = getting to a useable state though. If SPARC is to remain a supported = architecture, then we'll probably be using an external toolchain for it, = unless someone wants to spend a couple of months chasing bugs in the = LLVM SPARC back end. Oracle seems to be being quite effective at = killing SPARC64 as an architecture for running anything other than = Oracle appliances, but SPARC32 is still quite popular in aerospace so it = may still be an interesting platform in a few years. David --Apple-Mail=_44BBE6AB-A070-4794-A716-1A9712C2128B 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 iQIcBAEBAgAGBQJSIvOtAAoJEKx65DEEsqIduRQP/AxMrYQDz83DCcd41PHY7+dx GpkOpbW9GKbMr6GM5WbXi8wdUc0aYsl1GZ9wKjvf2wKia+LgHYgSxHehv4/FArTQ zy+Ix//m+bdSw+8PLSZQm7Rh9PAooNhNDF1YHKMrufXq/uZ8L7iL/LUNqV4A+gsR jDlAvCyNIut1M6ZWbjHrRexGbWgVO5Bw1Gd/eYWEIaygJt6D9acN8EbRfBJHWDxe ov59JZOAg6E7oLnWxVgt88WFv3XobuSbLXjOwCiCRSDvJT5TnDrgQ/I+SBR5G2tp U05pXb98apvqid8z9w3GY1WyB6j5HhKKkqr2dfHx5XFzOgCXvO6k63KFrxiB09ZF CJv7cv1CgM/VHb6RmpfCOHsepmePzh1d+RQnDd+YmNfWOP7aKmGN1Dskx1pqPVVH VKg1Ko5XvDAj92ncRwzfrgkVA4wdJMnlLDmOF34SNQ9bs0DAzuplzmVq0sZ2nCdb hMMlUo82VrENFjcRUYar2LZo56p1Dj6fFG8StHjdMarxLxZ08ASFvOeIjgTg6kPN ZYSb5N6nt1taklMN49XIG4NphWj7a3W3uOgF/eML/NNHAcrYVmoZoDSayA2nkUU8 oWFa3DBffDuPi8fiLaMgww18BkjYFpQC+XSHkGfGllqDISDRAWvI5JFU6r1PPv7d b22lJeW+BnheeZDZXm0k =h0Hq -----END PGP SIGNATURE----- --Apple-Mail=_44BBE6AB-A070-4794-A716-1A9712C2128B--