GCC withdraw
Benjamin Kaduk
kaduk at MIT.EDU
Sun Sep 1 01:53:56 UTC 2013
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.
More information about the freebsd-current
mailing list