patch to add AES intrinsics to gcc

[Warner Losh]

On Aug 23, 2013, at 4:01 PM, Alfred Perlstein wrote:

> On 8/23/13 3:35 AM, David Chisnall wrote:
>> On 23 Aug 2013, at 10:58, Bernhard Fröhlich <decke at freebsd.org> wrote:
>> 
>>> I don't know if you are aware that IF you really do that we will have serious
>>> problems to ship packages for 10. USE_GCC=any is the fallback in the
>>> portstree for all ports that are unable to build with clang which was introduced
>>> when HEAD switched to clang as default cc. Right now there are 150 ports in
>>> the tree that use this fallback and quite a few of them are high profile ports:
>>> 
>>> the highlights:
>>> audio/nas devel/mingw32-binutils emulators/qemu emulators/virtualbox-ose
>>> emulators/wine lang/go lang/v8 mail/courier math/fftw3 multimedia/libxine
>>> multimedia/gstreamer multimedia/gstreamer-plugins multimedia/x264
>>> security/clamav
>>> 
>>> the full list:
>>> http://dpaste.com/1354075/
>>> 
>>> A possible hack could be to add a check for USE_GCC=any to behave like
>>> a USE_GCC=yes on HEAD on the affected platforms. This pulls in lang/gcc
>>> from ports for a lot of people on HEAD I suppose.
>>> 
>>> We certainly need to do that switch to remove the ancient gcc from base
>>> some time but with my portmgr hat on I can only say we don't plan to do that
>>> before 10.0 especially not if we are only talking about a few weeks time window.
>> That is unfortunate.  We have said for over a year that 10.0 should not ship with gcc.  I can delay committing the patch to flip the switch until later in the code slush, if re approves, but ports that require gcc should be building with gcc from ports (which will also improve code quality, as gcc 4.6/7 produce significantly better code than 4.2.1).
>> 
>> David
>> 
>> _______________________________________________
>> 
> Why can't ports just then add the old-version of GCC?  This tight coupling between src and ports is screwing us over for far too long.

ports already has various gcc versions in ports, needed for dozens of ports that require newer gcc, and this could be adopted for the gcc from base issue. But that's not the issue. It is making the ports that need it use it, and from the quoted message it sounds like that would take work. Work takes time, and the window is closing.

> If src needs to move on, and it surely seems like it does, then ports needs to adapt.

I'd dispute the 'and surely it seems like it does' part of this. Non x86 architectures will continue to use gcc because clang just isn't ready at this time for them. Some are very close (arm), some are close (powerpc64, mips*), some are no where near ready, or will never be ready (sparc64, ia64). There's no coherent, documented plan for these absent gcc at the moment. There are lots of pieces there, and those pieces will form the basis of the solution (+handbook updates) for the removal of gcc in 11, but we just aren't there yet.

> No offense to either team, but this is just common sense.

The only ones that would really matter are ones in any bootstrap path we might need for external toolchains. Since qemu is the basis for cross building ports, it is disturbing to see that on the list. I know qemu has, in the past, been sensitive to compiler versions, as are many of the emulators in the tree. It might not be a simple matter to just use gcc 4.6 or 4.7 for some of the items on the list. When I've moved gcc versions and had problems with FOSS it is either due to new warnings/errors and language violations. Some of these are trivial to fix, others reveal fundamental flaws in the code and many changes are needed. Sometimes newer compilers also have optimizations bugs (as opposed to language violations now optimized differently) which break things at run-time, despite things appearing to compile. These aren't insurmountable problems, but do take time to implement and test.

Warner