Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 31 Aug 2013 21:53:45 -0400 (EDT)
From:      Benjamin Kaduk <kaduk@MIT.EDU>
To:        David Chisnall <theraven@freebsd.org>
Cc:        toolchain@freebsd.org, FreeBSD Current <current@freebsd.org>
Subject:   Re: GCC withdraw
Message-ID:  <alpine.GSO.1.10.1308312147110.16692@multics.mit.edu>
In-Reply-To: <98D31DD3-8A1D-46ED-9BF6-9EBE39640860@freebsd.org>
References:  <20130822200902.GG94127@funkthat.com> <201308291344.25562.jhb@freebsd.org> <A981C965-D625-458B-B0AB-171C983AEA42@FreeBSD.org> <201308301041.18874.jhb@freebsd.org> <20130831073330.GC36239@funkthat.com> <98D31DD3-8A1D-46ED-9BF6-9EBE39640860@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.1.10.1308312147110.16692>