Re: patch to add AES intrinsics to gcc

On 08/23/13 07:30, Ian Lepore wrote:
> On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote:
>> On 23 Aug 2013, at 11:42, Julian Elischer <julian_at_freebsd.org> wrote:
>>
>>> no, I believe we have said that 10 would ship with clang by default. NO mention was made about gcc being absent, and I am uncomfortable with taking that step yet. Having gcc just present, will not hurt you..  even after it is gone we will  need to support those who will be replacing clang with newer versions of gcc in hteir own products.
>> The plan is not to delete gcc from the tree, it is to disable building gcc by default when clang is the system compiler.  If you are building products then you are perfectly at liberty to set WITH_GCC=yes in your src.conf.
>>
>> Our gcc is from 2007.  It has no C11, no C++11 support.  It has bugs in its atomic generation so you can't use it sensibly without lots of inline assembly (which it doesn't support for newer architectures) for multithreaded things.
>>
>> Our libstdc++ is ancient and doesn't work with modern C++ codebases.  Putting them in the base system means that people will use them.  If anyone wants them to remain, then speak now and this will be taken as your volunteering to:
>>
>> - Maintain our forks of both gcc and libstdc++
>> - Handle every single PR that is filed by people using these
>>
>> If you are willing to do this, then that's great.  If not, then you are asking other people to support ancient codebases that they are not using.
>>
>> David
>>
> I don't understand, you start by pointing out that gcc will still be in
> the tree and usable, then you go on to point out that it it won't be
> supported or maintained unless someone volunteers to do that, and you
> seem to be doing your best to discourage anyone from volunteering.
> Doesn't that sort of moot the point that the source isn't being deleted?
>

It has to stay in the tree and usable -- at least for a while -- because 
not all of our Tier-2 platforms can build with clang yet. Those 
platforms, however, are typically not the ones that will require 
patching and maintenance (UltraSPARC 3s are not gaining any new features).

I think that turning it off frees us during the 10.x release lifetime to 
actually remove it if the maintenance burden becomes too high -- or to 
revert our decision to turn it off at any time. Having it on by default 
locks us in to maintaining it for the lifetime of the branch.
-Nathan