Date: Fri, 23 Aug 2013 16:37:50 -0600 From: Warner Losh <imp@bsdimp.com> To: Alfred Perlstein <alfred@freebsd.org> Cc: toolchain@FreeBSD.org, John-Mark Gurney <jmg@funkthat.com>, current@FreeBSD.org, "re@FreeBSD.org Engineering Team" <re@FreeBSD.org> Subject: Re: patch to add AES intrinsics to gcc Message-ID: <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> In-Reply-To: <5217DBAB.5030607@freebsd.org> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <CAE-m3X324rbdP_C=az4eO-EkMcR-yFAeRG7S4q%2BMUsnMezGddw@mail.gmail.com> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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=F6hlich <decke@freebsd.org> = wrote: >>=20 >>> 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=3Dany 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: >>>=20 >>> 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 >>>=20 >>> the full list: >>> http://dpaste.com/1354075/ >>>=20 >>> A possible hack could be to add a check for USE_GCC=3Dany to behave = like >>> a USE_GCC=3Dyes on HEAD on the affected platforms. This pulls in = lang/gcc >>> from ports for a lot of people on HEAD I suppose. >>>=20 >>> 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). >>=20 >> David >>=20 >> _______________________________________________ >>=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86032E72-A569-4946-B4F8-26F687067B31>