From owner-freebsd-toolchain@FreeBSD.ORG Sun Sep 1 01:53:56 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 39E4AE62; Sun, 1 Sep 2013 01:53:56 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id ABBC72EF5; Sun, 1 Sep 2013 01:53:55 +0000 (UTC) X-AuditID: 12074422-b7ef78e000000935-57-52229e2d5e87 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 28.EA.02357.D2E92225; Sat, 31 Aug 2013 21:53:49 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r811rmoh015198; Sat, 31 Aug 2013 21:53:48 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r811rk2P013951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 31 Aug 2013 21:53:47 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r811rj3R001548; Sat, 31 Aug 2013 21:53:45 -0400 (EDT) Date: Sat, 31 Aug 2013 21:53:45 -0400 (EDT) From: Benjamin Kaduk To: David Chisnall Subject: Re: GCC withdraw In-Reply-To: <98D31DD3-8A1D-46ED-9BF6-9EBE39640860@freebsd.org> Message-ID: 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> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqras7TynI4P81dosJV34wWSy+/4jZ YsfO62wOzB4zPs1nCWCM4rJJSc3JLEst0rdL4Mp4svUBY8F9nordf5IbGP9wdjFyckgImEhM P/mYFcIWk7hwbz1bFyMXh5DAPkaJOWfuQDkbGSW2/vrGDuEcYpJ41rSIFcJpYJS4/OkTWD+L gLZE0/tWNhCbTUBFYuabjWC2iICmxKTLexhBbGYBB4kPfzqZuhg5OIQFJCV2Ha0DCXMK2Ev8 7j7EAmLzCjhKvP/wEWp+J5PEg0WLwRKiAjoSq/dPgSoSlDg58wkLxExLiXN/rrNNYBSchSQ1 C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1TvdzMEr3UlNJNjKBQZXdR2sH486DSIUYB DkYlHt6ASKUgIdbEsuLK3EOMkhxMSqK8GycChfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwMjQB 5XhTEiurUovyYVLSHCxK4rzPnp4NFBJITyxJzU5NLUgtgsnKcHAoSfAGzgVqFCxKTU+tSMvM KUFIM3FwggznARpuBlLDW1yQmFucmQ6RP8WoKCXOawySEABJZJTmwfXCUskrRnGgV4R5ZUGq eIBpCK77FdBgJqDB1yYqggwuSURISTUwZh43SLZYuN7Z5QlDxc31zvNdXJdpeUeE301ZYKmz 7+g17RXfCy9eOF99nW3ahjMFPVJM/bsnXtqoF70qL/QCq8s9kxKJqvjZ2v4/pvLkPmF69rRu jp/hF+Pgv6aWvsKTlasSFn+vuKmqGz/Vdq5oQajR5d7Aun6L9mfnZj869bZEfX3FUY97SizF GYmGWsxFxYkAQYHGrQADAAA= Cc: toolchain@freebsd.org, FreeBSD Current X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 01:53:56 -0000 Sorry for adding to the long thread. On Sat, 31 Aug 2013, David Chisnall wrote: > However, we want to be able to make it unsupported at some point in the > 10.x series when there is a polished alternative for every supported > architecture (either when they've moved to clang or when the XCC stuff 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". -Ben > is fully documented in the handbook and tested in a large variety of > configurations and once our forked binutils and is available as a > package and we have cross-gcc that uses it). If this doesn't happen by > the time 10.x is EOL'd then I'll be sad, but we still have the fall-back > position of gcc in base for the entire 10.x. If it does happen, then we > can start more aggressively phasing out gcc in the base system.