Re: patch to add AES intrinsics to gcc
On Aug 27, 2013, at 8:46 AM, Nathan Whitehorn wrote: On 08/25/13 18:41, Gerald Pfeifer wrote: On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: I object. Many ports that compiles perfectly on gcc 4.2.1 can't be compiled with lang/gcc. I checked this once and the number of ports that require strictly gcc 4.2.1 was bigger for me then number of ports that can't be compiled with clang but fill fine on lang/gcc. I'll gonna recheck whether lang/gcc42 is sufficient for them. But I have that bad feeling... If there are ports that use USE_GCC=any and do not build with lang/gcc, these should have USE_GCC=4.2 -- without a '+'! -- not USE_GCC=any. It'll be great if you can fix any such port. It would be particularly nice if we had a port with FreeBSD's many patches to 4.2. lang/gcc42 (and 46 and lang/gcc) do not build on powerpc64, for example, while our in-tree GCC does. I think it would be more than nice to have. I'd argue that these issues need to be addressed before we can claim to have a full external-supported toolchain story that's integrated and well tested and covers the needs of all our users. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 08/25/13 18:41, Gerald Pfeifer wrote: On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: I object. Many ports that compiles perfectly on gcc 4.2.1 can't be compiled with lang/gcc. I checked this once and the number of ports that require strictly gcc 4.2.1 was bigger for me then number of ports that can't be compiled with clang but fill fine on lang/gcc. I'll gonna recheck whether lang/gcc42 is sufficient for them. But I have that bad feeling... If there are ports that use USE_GCC=any and do not build with lang/gcc, these should have USE_GCC=4.2 -- without a '+'! -- not USE_GCC=any. It'll be great if you can fix any such port. It would be particularly nice if we had a port with FreeBSD's many patches to 4.2. lang/gcc42 (and 46 and lang/gcc) do not build on powerpc64, for example, while our in-tree GCC does. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Mon, 26 Aug 2013, Claude Buisson wrote: Perhaps you could have a look at the fact that lang/gcc is at 4.6.3, and lang/gcc46 is no more a snapshot but a true release 4.6.4. I am aware of that. Owed to a strongly voiced desire by users, I am triggering a rebuild of lang/gcc as rarely as possible. So, instead of going from 4.6.4 and soon 4.7.x, I submitted an update to 4.7.3 to portmgr for an -exp run last weekend. IMHO, lang/gcc must be discontinued, or updated to 4.6.4 and lang/gcc46 discontinued ? Neither. :-) Of all lang/gcc* ports, lang/gcc is the one to use (and hence keep). And lang/gcc46, lang/gcc47,... will remain in place for a while for use by those interested in an older version (or broken ports requiring one) or those interested in tracker newer versions. Gerald ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
Can all such ports be identified with a ports build run in a special chroot without FreeBSD's FCC installed? Sent from my iPad On Aug 25, 2013, at 7:41 PM, Gerald Pfeifer ger...@pfeifer.com wrote: On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: I object. Many ports that compiles perfectly on gcc 4.2.1 can't be compiled with lang/gcc. I checked this once and the number of ports that require strictly gcc 4.2.1 was bigger for me then number of ports that can't be compiled with clang but fill fine on lang/gcc. I'll gonna recheck whether lang/gcc42 is sufficient for them. But I have that bad feeling... If there are ports that use USE_GCC=any and do not build with lang/gcc, these should have USE_GCC=4.2 -- without a '+'! -- not USE_GCC=any. It'll be great if you can fix any such port. Gerald ___ freebsd-toolch...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 08/26/2013 03:12, Gerald Pfeifer wrote: On Sat, 24 Aug 2013, Warner Losh wrote: If you push gcc out to a port, and you have the 'external compiler' toolchain support working correctly enough to build with this, why don't we just push clang out to a port, and be done with it? This is a stupid idea. It kills the tightly integrated nature of FreeBSD. I'd say it is far too radical a departure and opens up a huge can of which version of what compiler nightmare that we've largely dodged to date because we had one (or maybe two) compilers in the base system. I am working towards establishing lang/gcc as _the_ version of GCC to use for ports. Today I looked at a couple of those GCC cross-compilers we have in ports, and I have to admit I am not thrilled. Each of those I saw copies a lot from (older version of my ports), each has a different maintainer, each has some additions, and there is little consistency. Perhaps you could have a look at the fact that lang/gcc is at 4.6.3, and lang/gcc46 is no more a snapshot but a true release 4.6.4. IMHO, lang/gcc must be discontinued, or updated to 4.6.4 and lang/gcc46 discontinued ? Are these the base of 'external compiler' toolchain support? Are there any plans to increase consistency and reduce redundancy? In an ideal world, could those become slave ports of lang/gcc? Gerald Claude Buisson ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Aug 25, 2013, at 7:12 PM, Gerald Pfeifer wrote: On Sat, 24 Aug 2013, Warner Losh wrote: If you push gcc out to a port, and you have the 'external compiler' toolchain support working correctly enough to build with this, why don't we just push clang out to a port, and be done with it? This is a stupid idea. It kills the tightly integrated nature of FreeBSD. I'd say it is far too radical a departure and opens up a huge can of which version of what compiler nightmare that we've largely dodged to date because we had one (or maybe two) compilers in the base system. I am working towards establishing lang/gcc as _the_ version of GCC to use for ports. Today I looked at a couple of those GCC cross-compilers we have in ports, and I have to admit I am not thrilled. Each of those I saw copies a lot from (older version of my ports), each has a different maintainer, each has some additions, and there is little consistency. Are these the base of 'external compiler' toolchain support? Are there any plans to increase consistency and reduce redundancy? In an ideal world, could those become slave ports of lang/gcc? In my experience, this has grown up rather hap-hazardly. Some more order here would be good. In the past, for example, some ports had some of the FreeBSD fixes, but not all so while I could build FreeBSD/mips gcc out of /usr/src, I couldn't do that, even for the (then current) gcc42 port since some of the fixes hadn't made it up stream. In an ideal world, we'd be able to build any version of gcc for any FreeBSD platform (or have it fail up front) so we can use that as an external toolchain. The initial work I did for external toolchains, that Brooks reworked (or rewrote from scratch, I can't recall which he did), was with make xdev in the tree... And that has its own set of pros and cons... All of which are really a tangent, so I'll leave it at that. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote: I object. Many ports that compiles perfectly on gcc 4.2.1 can't be compiled with lang/gcc. I checked this once and the number of ports that require strictly gcc 4.2.1 was bigger for me then number of ports that can't be compiled with clang but fill fine on lang/gcc. I'll gonna recheck whether lang/gcc42 is sufficient for them. But I have that bad feeling... If there are ports that use USE_GCC=any and do not build with lang/gcc, these should have USE_GCC=4.2 -- without a '+'! -- not USE_GCC=any. It'll be great if you can fix any such port. Gerald ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Fri, 23 Aug 2013, Bernhard Fröhlich wrote: lang/gcc42 is on the list of ports that have USE_GCC=any. So you would need to fix it first to be able to compile it with clang 3.3 from base. I don't think so. :-) You can install lang/gcc which builds just fine with clang, and then use lang/gcc to build lang/gcc42. In fact, if you have a system without GCC in the base, this should happen automatically when you build lang/gcc42. Does this not work? We are not trying to build everything with lang/gcc but just the ports that have USE_GCC=any in their Makefile. ...and those that have USE_GCC=yes in their Makefile. The difference between USE_GCC=yes and USE_GCC=any is that the later is there to support the transition period and uses /usr/bin/gcc if present. Personally, I would stop relying on /usr/bin/gcc (even if present) and use the lang/gcc port in all cases. That reduces the number of different scenarios to test, but will pull in lang/gcc in some more cases and may meet some resistance therefore. Gerald___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Fri, 23 Aug 2013, Bernhard Fröhlich wrote: 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. I am planning to work on this a bit more once the two patches I submitted to portmgr this weekend (updating math/mpc, updating lang/gcc and the default ports version of GCC from 4.6 to 4.7) have made it into the tree. That said, already today when USE_GCC=any is specified and /usr/bin/gcc does not exist, USE_GCC=any basically becomes USE_GCC=yes and uses a current version of GCC, lang/gcc by default unless a different version is installed. Is this not working for you? Is there anything else that you'd like to see in Mk/bsd.gcc.mk? Gerald___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Sat, 24 Aug 2013, Warner Losh wrote: If you push gcc out to a port, and you have the 'external compiler' toolchain support working correctly enough to build with this, why don't we just push clang out to a port, and be done with it? This is a stupid idea. It kills the tightly integrated nature of FreeBSD. I'd say it is far too radical a departure and opens up a huge can of which version of what compiler nightmare that we've largely dodged to date because we had one (or maybe two) compilers in the base system. I am working towards establishing lang/gcc as _the_ version of GCC to use for ports. Today I looked at a couple of those GCC cross-compilers we have in ports, and I have to admit I am not thrilled. Each of those I saw copies a lot from (older version of my ports), each has a different maintainer, each has some additions, and there is little consistency. Are these the base of 'external compiler' toolchain support? Are there any plans to increase consistency and reduce redundancy? In an ideal world, could those become slave ports of lang/gcc? Gerald ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 23 Aug 2013, at 13:30, Bernhard Fröhlich de...@freebsd.org wrote: lang/gcc42 is on the list of ports that have USE_GCC=any. So you would need to fix it first to be able to compile it with clang 3.3 from base. What is the issue with the gcc 4.2.1 build (aside from the fact that it has a terrifying number of warnings when built with any recent compiler)? The gcc 4.2.1 in base builds with clang - that's how we currently build it in head... David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 23 Aug 2013, at 23:37, Warner Losh i...@bsdimp.com wrote: 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. The plan, which has been discussed on mailing lists, on IRC, and at DevSummits is for tier 2 ports to depend on an external toolchain. For those vendors that are not prevented from using GPLv3 compilers, this means that they will be able to take advantage of, for example, the significant improvements to the MIPS and PowerPC back ends that gcc has had over the last 6 years. For everyone else, it will mean installing a compiler from ports. For now, tier 2 architectures will continue to build a toolchain from the src tree and use that. By 11.0, gcc will be gone from the base system and they will be required to use something external if they are not supported by clang. Brooks has been working hard on making this easy, and it is generally an improvement for cross-building embedded systems as the cross-compile toolchain is no longer rebuilt every time you change a file in the kernel, resulting in faster builds. It is also easier to use toolchains provided by chip vendors, which is something that MIPS and ARM vendors have been asking for for a very long time. For x86 and ARMv6/7, Clang has been the default compiler for a long time and gcc has been increasingly problematic (for example, our gcc does not support ARM EABI, which will be the default in 10.0 for ARMv6 and later, so if you want to build for a modern ARM chip then you need either clang or a more recent gcc than we ship). Claiming that this is something done at the expense of non-x86 architectures is highly misleading, as improving ARM support is one of the driving factors behind the switch. If you are shipping a product that relies on gcc, then for the 10.x timeframe, you are free to build and use the gcc from the base system, and the tinderboxes will prevent any non-optional components from being modified in such a way that they can't build with this gcc. In the 11.x timeframe, architectures that aren't supported by clang will need an external toolchain. AMD, Intel, AMD, Oracle, ARM, and MIPS are all actively contributing to LLVM and Clang, so the only platform that is unlikely to have an LLVM back end in the 11.0 timeframe is IA64, and if you really care about IA64 then Intel will happily sell you a compiler that does a much better job than GCC of targeting this architecture. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: patch to add AES intrinsics to gcc
On Aug 24, 2013, at 4:05 AM, David Chisnall wrote: On 23 Aug 2013, at 23:37, Warner Losh i...@bsdimp.com wrote: 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. The plan, which has been discussed on mailing lists, on IRC, and at DevSummits is for tier 2 ports to depend on an external toolchain. For those vendors that are not prevented from using GPLv3 compilers, this means that they will be able to take advantage of, for example, the significant improvements to the MIPS and PowerPC back ends that gcc has had over the last 6 years. For everyone else, it will mean installing a compiler from ports. That's the plan for FreeBSD 11, yes. For FreeBSD 10, gcc remains in the tree. For now, tier 2 architectures will continue to build a toolchain from the src tree and use that. By 11.0, gcc will be gone from the base system and they will be required to use something external if they are not supported by clang. Brooks has been working hard on making this easy, and it is generally an improvement for cross-building embedded systems as the cross-compile toolchain is no longer rebuilt every time you change a file in the kernel, resulting in faster builds. It is also easier to use toolchains provided by chip vendors, which is something that MIPS and ARM vendors have been asking for for a very long time. Yes. Many of the building blocks are in place, but they haven't been stitched together entirely yet. The 11 time frame is plenty of time to tie up the loose ends and rough edges that are there, as well as to ensure you can cross build a system, then do a native build on that system with external toolchains... For x86 and ARMv6/7, Clang has been the default compiler for a long time and gcc has been increasingly problematic (for example, our gcc does not support ARM EABI, which will be the default in 10.0 for ARMv6 and later, so if you want to build for a modern ARM chip then you need either clang or a more recent gcc than we ship). Claiming that this is something done at the expense of non-x86 architectures is highly misleading, as improving ARM support is one of the driving factors behind the switch. I'm sorry, but that's not quite right. Our gcc *DOES* support arm EABI with soft float. In fact, that's how we're using it now and how we're using clang now as well. clang support for ARM is still shaky, even in -current. EABI with hard float hasn't been done, and will require a newer gcc and/or clang, but we're not entirely there yet. The fallback for weird bugs is still recompile with the in-tree gcc and often that has fixed issues that people hit either with clang, or with assumptions about generated code that weren't quite true with clang and needed to be fixed in our kernel. But *ALL* the other non-x86 architectures are significantly worse with clang. ARM is marginally the same, but we're still some issues we're fighting through with ports and such. I think I was clear about which ones were affected, and how though in my note. If you are shipping a product that relies on gcc, then for the 10.x timeframe, you are free to build and use the gcc from the base system, and the tinderboxes will prevent any non-optional components from being modified in such a way that they can't build with this gcc. In the 11.x timeframe, architectures that aren't supported by clang will need an external toolchain. Yup. And the external toolchain support will need to be well documented and we need a cross building/installing external toolchain story that's better. It works well enough to generate a system now, but not quite well enough to generate a self-hosting system (which is required for the ports cross-build-on-qemu solution). AMD, Intel, AMD, Oracle, ARM, and MIPS are all actively contributing to LLVM and Clang, so the only platform that is unlikely to have an LLVM back end in the 11.0 timeframe is IA64, and if you really care about IA64 then Intel will happily sell you a compiler that does a much better job than GCC of targeting this architecture. Yes. I'm totally on board with that for the 11 time frame. 32-bit powerpc had issues, and isn't in your list. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
You know, I could be a total jerk and say: If you push gcc out to a port, and you have the 'external compiler' toolchain support working correctly enough to build with this, why don't we just push clang out to a port, and be done with it? ... just saying. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 8/24/13 9:33 AM, Adrian Chadd wrote: You know, I could be a total jerk and say: If you push gcc out to a port, and you have the 'external compiler' toolchain support working correctly enough to build with this, why don't we just push clang out to a port, and be done with it? ... just saying. -adrian Are you calling me a total jerk? :) I'm fine with that because I agree. -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Sat, Aug 24, 2013 at 01:05:13AM +0400, Slawa Olhovchenkov wrote: On Fri, Aug 23, 2013 at 06:54:44AM -0700, Adrian Chadd wrote: Hi! If firewire code doesn't build on clang correctly, have you filed a bug so it gets looked at before 10.0 is released? that's pretty broken code/behaviour. How I can do it correctly? Currently in src.conf: WITHOUT_CLANG=yes WITHOUT_CLANG_IS_CC=yes Need recompile world? System build from sources Jun 8. clang -- Jan 9. I build world w/o this options. After this I build kernel and install it. Reboot. acpiconf -s 3. power button. I got NMI. Sorry, dump don't allowed -- dump device don't ready at this moment. This is screenphoto http://zxy.spb.ru/13080005.jpg Kernel builded by GCC succeseful resuming (w/o NMI). Is it sufficient information for open PR? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Sat, Aug 24, 2013 at 12:33 PM, Adrian Chadd adr...@freebsd.org wrote: You know, I could be a total jerk and say: If you push gcc out to a port, and you have the 'external compiler' toolchain support working correctly enough to build with this, why don't we just push clang out to a port, and be done with it? ... just saying. +1 GREAT idea!!! that is a better plan for 11.x -- Sam Fourman Jr. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Aug 24, 2013, at 3:04 PM, Sam Fourman Jr. wrote: On Sat, Aug 24, 2013 at 12:33 PM, Adrian Chadd adr...@freebsd.org wrote: You know, I could be a total jerk and say: If you push gcc out to a port, and you have the 'external compiler' toolchain support working correctly enough to build with this, why don't we just push clang out to a port, and be done with it? ... just saying. +1 GREAT idea!!! that is a better plan for 11.x This is a stupid idea. It kills the tightly integrated nature of FreeBSD. I'd say it is far too radical a departure and opens up a huge can of which version of what compiler nightmare that we've largely dodged to date because we had one (or maybe two) compilers in the base system. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. David On 22 Aug 2013, at 21:09, John-Mark Gurney j...@funkthat.com wrote: In my work to get AES-NI performance in a better state and the fact that we haven't deprecated gcc yet, I have developed another patch to add the appropriate AES intrinstic headers to gcc. The patch is available at: https://people.freebsd.org/~jmg/gcc.aes.intrin.patch I did have to change the opth-gen.awk script, since it wouldn't let me use bit 31, and recent changes to gcc used up all the remaining bits. I also was unable to add the -mpclmul option because of running out of these bits. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-toolch...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org signature.asc Description: Message signed with OpenPGP using GPGMail
Re: patch to add AES intrinsics to gcc
on 23/08/2013 12:16 David Chisnall said the following: I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. I have an alternative proposal (to re@ and core@) to set WITHOUT_CLANG_IS_CC in stable/10 or at least releng/10.0. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
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. -- Bernhard Froehlich http://www.bluelife.at/ On Fri, Aug 23, 2013 at 11:16 AM, David Chisnall thera...@freebsd.org wrote: I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. David On 22 Aug 2013, at 21:09, John-Mark Gurney j...@funkthat.com wrote: In my work to get AES-NI performance in a better state and the fact that we haven't deprecated gcc yet, I have developed another patch to add the appropriate AES intrinstic headers to gcc. The patch is available at: https://people.freebsd.org/~jmg/gcc.aes.intrin.patch I did have to change the opth-gen.awk script, since it wouldn't let me use bit 31, and recent changes to gcc used up all the remaining bits. I also was unable to add the -mpclmul option because of running out of these bits. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-toolch...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 23 Aug 2013, at 10:58, Bernhard Fröhlich de...@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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 8/23/13 6:35 PM, David Chisnall wrote: On 23 Aug 2013, at 10:58, Bernhard Fröhlich de...@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). 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. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
23.08.2013 13:16, David Chisnall пишет: I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. Isn't it a POLA violation? As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 23 Aug 2013, at 11:42, Julian Elischer jul...@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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
Hi! I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. Isn't it a POLA violation? As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. If the 150 ports that only work with gcc, all work with a ports gcc and do not need the gcc from base, would the following be OK ? - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; -- p...@opsec.eu+49 171 3101372 7 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Fri, Aug 23, 2013 at 12:35 PM, David Chisnall thera...@freebsd.org wrote: On 23 Aug 2013, at 10:58, Bernhard Fröhlich de...@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). I have asked the question of when will gcc be removed from base multiple times over the last year and I got varying results back with the majority saying after 10. I'm just trying to say that It looks like some people in src also don't expect it to be removed in 10. Anyway bapt already did some testing without gcc in base on HEAD and the results were bad but not totally awful. We will see if we can fix the most important ones in time before 10 but we can't promise anything. If someone wants to have a look at the failures with no gcc in base on HEAD: http://pb2.nyi.freebsd.org/bulk/nogcc-default/2013-08-04_01h01m20s/ (this also includes HEAD failures caused by clang) -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Fri, Aug 23, 2013 at 06:42:21PM +0800, Julian Elischer wrote: On 8/23/13 6:35 PM, David Chisnall wrote: On 23 Aug 2013, at 10:58, Bernhard Fr?hlich de...@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). no, I believe we have said that 10 would ship with clang by default. 10 from this winner have broken firewire code when building by clang -- cannot resume from sleep. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
23.08.2013 12:58, Bernhard Fröhlich 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. I object. Many ports that compiles perfectly on gcc 4.2.1 can't be compiled with lang/gcc. I checked this once and the number of ports that require strictly gcc 4.2.1 was bigger for me then number of ports that can't be compiled with clang but fill fine on lang/gcc. I'll gonna recheck whether lang/gcc42 is sufficient for them. But I have that bad feeling... -- Sphinx of black quartz, judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
on 23/08/2013 14:06 David Chisnall said the following: 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. On the other hand these tools are perfect for building FreeBSD kernel and base. Extrapolating my experience with base GCC I am very confident in it as a FreeBSD development tool. Extrapolating my experience with Clang I am not yet confident in it as a FreeBSD development tool. I do not care about C11, C++11 and modern C++ codebases. I care about what's in /usr/src and what gets compiled by buildkernel/buildworld. That's just me, of course. But, OTOH, those who care modern C++ codebases should be perfectly capable to install a compiler from ports or switch to clang as their default compiler. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Fri, Aug 23, 2013 at 2:12 PM, Volodymyr Kostyrko c.kw...@gmail.com wrote: 23.08.2013 12:58, Bernhard Fröhlich 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. I object. Many ports that compiles perfectly on gcc 4.2.1 can't be compiled with lang/gcc. I checked this once and the number of ports that require strictly gcc 4.2.1 was bigger for me then number of ports that can't be compiled with clang but fill fine on lang/gcc. I'll gonna recheck whether lang/gcc42 is sufficient for them. But I have that bad feeling... lang/gcc42 is on the list of ports that have USE_GCC=any. So you would need to fix it first to be able to compile it with clang 3.3 from base. We are not trying to build everything with lang/gcc but just the ports that have USE_GCC=any in their Makefile. Per default all ports are still build with cc from base so clang 3.3 on HEAD. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote: On 23 Aug 2013, at 11:42, Julian Elischer jul...@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? -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 08/23/13 07:26, Andriy Gapon wrote: on 23/08/2013 14:06 David Chisnall said the following: 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. On the other hand these tools are perfect for building FreeBSD kernel and base. Extrapolating my experience with base GCC I am very confident in it as a FreeBSD development tool. Extrapolating my experience with Clang I am not yet confident in it as a FreeBSD development tool. This isn't even true. As CPUs gain new features, the set of available intrinsics gets more and more ancient, requiring ever more patching, workarounds, and #ifdef. Just look at the original subject of this thread! We're just talking about the default of a make.conf setting here. Switching to clang is a long-term goal of the project for good reason. Other vendors (Apple, for instance) have made the plunge first. This seems like as good a time as any to do it. And if it goes wrong somehow, we have lots of BETAs and it is trivial to change back at any time. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 23 Aug 2013, at 13:26, Andriy Gapon a...@freebsd.org wrote: On the other hand these tools are perfect for building FreeBSD kernel and base. Extrapolating my experience with base GCC I am very confident in it as a FreeBSD development tool. Extrapolating my experience with Clang I am not yet confident in it as a FreeBSD development tool. Nathan has already dealt with this. I do not care about C11, C++11 and modern C++ codebases. I care about what's in /usr/src and what gets compiled by buildkernel/buildworld. That's just me, of course. But, OTOH, those who care modern C++ codebases should be perfectly capable to install a compiler from ports or switch to clang as their default compiler. So you don't want a working debugger? Our gdb doesn't work at all on MIPS and barely works with code compiled with clang or a recent gcc. We are planning on importing LLDB soon (Ed Maste has been working on it, funded by the FreeBSD Foundation), and it is a C++11 code base. It will not build with our gcc or with our libstdc++ (and, in fact, since it uses the LLVM libraries, will require LLVM in base to link libc++). Or perhaps you don't care about flattened device trees. The device tree compiler that we have in base is written in C++ and contains numerous occurrences of ugly code to make it work with old compilers. I will be very happy to remove a load of hacks once C++11 support is available in the base system (not for 10.0, as dtc is used on a lot of tier 2 archs where gcc is still default). David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
on 23/08/2013 15:34 Nathan Whitehorn said the following: On 08/23/13 07:26, Andriy Gapon wrote: on 23/08/2013 14:06 David Chisnall said the following: 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. On the other hand these tools are perfect for building FreeBSD kernel and base. Extrapolating my experience with base GCC I am very confident in it as a FreeBSD development tool. Extrapolating my experience with Clang I am not yet confident in it as a FreeBSD development tool. This isn't even true. It's been true for me. As CPUs gain new features, the set of available intrinsics gets more and more ancient, requiring ever more patching, workarounds, and #ifdef. Just look at the original subject of this thread! Yes. I am more comfortable with incremental changes. Bugs in those can be pinpointed quite easily and I do not affect those who don't use the new features. We're just talking about the default of a make.conf setting here. Switching to clang is a long-term goal of the project for good reason. I agree. Other vendors (Apple, for instance) have made the plunge first. This seems like as good a time as any to do it. And if it goes wrong somehow, we have lots of BETAs and it is trivial to change back at any time. I am totally comfortable with clang being default in head. I am also comfortable with gcc not being built by default in head. I am not yet comfortable with clang being default in a release. Even .0 one. JIMHO, it needs to age a little bit more. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
on 23/08/2013 15:56 David Chisnall said the following: So you don't want a working debugger? Our gdb doesn't work at all on MIPS and barely works with code compiled with clang or a recent gcc. I am capable of using devel/gdb. Or do you mean kernel debugger? We are planning on importing LLDB soon (Ed Maste has been working on it, funded by the FreeBSD Foundation), and it is a C++11 code base. It will not build with our gcc or with our libstdc++ (and, in fact, since it uses the LLVM libraries, will require LLVM in base to link libc++). There are multiple possible solutions to this issue. And note that I do support having clang in base and it being the default in head. Or perhaps you don't care about flattened device trees. To be honest - no, I don't care about them. The device tree compiler that we have in base is written in C++ and contains numerous occurrences of ugly code to make it work with old compilers. I will be very happy to remove a load of hacks once C++11 support is available in the base system (not for 10.0, as dtc is used on a lot of tier 2 archs where gcc is still default). -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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 jul...@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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Aug 23, 2013, at 5:06 AM, David Chisnall wrote: On 23 Aug 2013, at 11:42, Julian Elischer jul...@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. Well, it isn't quite that cut and dried. The date that gcc is from is not relevant. It works today for most of the code out there. True, it doesn't have the latest features that a small fraction of the code needs, but it works well enough. And it also needs to be there for some upgrade paths. There's a use for gcc, and it will likely be needed for these paths. As such, it has to work. Doesn't matter if it is built by default or not, it simply has to keep working as well as it has been working for the past 5 years to fill these roles. For these tasks the nice C++ things simply don't matter or aren't relevant. c11 features can't be put into the base for some time still because of the issues on other architectures. We *HAVE* to have gcc on the other architectures. clang simply isn't ready for MIPS, and has several outstanding problems on ARM. While work is ongoing in these areas, clang simply won't be in as good a shape for !x86 as it is for x86 in the 10.0 time frame. So even if gcc is turned off by default in 10 on x86, it still has to work at least well enough to build the system and bootstrap clang. Turning it off by default or on by default doesn't change this, and the feature set that is used in 10 will basically be frozen soon, and the non-x86 architectures will require the MI parts continue to work. I don't see much decay that can happen in the x86MD parts that would break it... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On Aug 23, 2013, at 5:16 AM, Kurt Jaeger wrote: Hi! I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. Isn't it a POLA violation? As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. If the 150 ports that only work with gcc, all work with a ports gcc and do not need the gcc from base, would the following be OK ? - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; No. That breaks non x86 architecutres. gcc must remain in base for now, or there's no bootstrap ability. Nobody has done the lifting to cleanly integrate gcc as a port into buildworld, althogh Brooks' work gets us most of the way there. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On 23 Aug 2013, at 14:52, Warner Losh i...@bsdimp.com wrote: No. That breaks non x86 architecutres. gcc must remain in base for now, or there's no bootstrap ability. Nobody has done the lifting to cleanly integrate gcc as a port into buildworld, althogh Brooks' work gets us most of the way there. We've been using brooks' work to build the base system with an out-of-tree toolchain for some time now... David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: patch to add AES intrinsics to gcc
Hi! If firewire code doesn't build on clang correctly, have you filed a bug so it gets looked at before 10.0 is released? that's pretty broken code/behaviour. -adrian On 23 August 2013 04:46, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Fri, Aug 23, 2013 at 06:42:21PM +0800, Julian Elischer wrote: On 8/23/13 6:35 PM, David Chisnall wrote: On 23 Aug 2013, at 10:58, Bernhard Fr?hlich de...@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). no, I believe we have said that 10 would ship with clang by default. 10 from this winner have broken firewire code when building by clang -- cannot resume from sleep. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Aug 23, 2013, at 6:30 AM, Ian Lepore wrote: On Fri, 2013-08-23 at 12:06 +0100, David Chisnall wrote: On 23 Aug 2013, at 11:42, Julian Elischer jul...@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? If it is in the tree it's gotta work. And it has to be in the tree for !x86 architectures. So on or off for x86 doesn't really add to the load at all, and the C++/C11 stuff is a red herring. If it isn't cc, then people wanting clang by default won't care... And besides, ports aren't completely ready to kill it, so it has to work for them. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On Aug 23, 2013, at 7:54 AM, David Chisnall wrote: On 23 Aug 2013, at 14:52, Warner Losh i...@bsdimp.com wrote: No. That breaks non x86 architecutres. gcc must remain in base for now, or there's no bootstrap ability. Nobody has done the lifting to cleanly integrate gcc as a port into buildworld, althogh Brooks' work gets us most of the way there. We've been using brooks' work to build the base system with an out-of-tree toolchain for some time now... I'll have to try the native build part of the cycle then... Early versions of the patch failed when you cross built the target, installed the target, but wound up with no compilers to bootstrap the external toolchains with to do native builds on the target. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
On Fri, Aug 23, 2013 at 03:02:18PM +0400, Boris Samorodov wrote: 23.08.2013 13:16, David Chisnall ??: I have a patch that I intend to commit before the 10.0 code slush that removes GCC and libstdc++ from the default build on platforms where clang is the system compiler. We definitely don't want to be supporting our 6-year-old versions of these for the lifetime of the 10.x branch. Isn't it a POLA violation? As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. +1 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: GCC withdraw (was: Re: patch to add AES intrinsics to gcc)
As for me I expect something like this: . 9.x gcc default and clang in base; . 10.x clang default and gcc in base; . 11.x gcc withdraw. There is also the concern whether clang in base will reliably build gcc required for some ports, and then there are those CPU architectures for which clang is nonexistent or not ready. Regarding those ports that build with the ancient gcc 4.2.1 but not with newer versions, that has to be considered a bug. Consider that Linux and the other BSDs use newer versions of gcc to build their base system and ports or pkgsrc. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 8/23/13 8:26 PM, Andriy Gapon wrote: on 23/08/2013 14:06 David Chisnall said the following: 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. On the other hand these tools are perfect for building FreeBSD kernel and base. Extrapolating my experience with base GCC I am very confident in it as a FreeBSD development tool. Extrapolating my experience with Clang I am not yet confident in it as a FreeBSD development tool. I do not care about C11, C++11 and modern C++ codebases. I care about what's in /usr/src and what gets compiled by buildkernel/buildworld. That's just me, of course. But, OTOH, those who care modern C++ codebases should be perfectly capable to install a compiler from ports or switch to clang as their default compiler. +1 I'd like to see it still be there if you need it in 10 in 11 it's in ports ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On Fri, Aug 23, 2013 at 06:54:44AM -0700, Adrian Chadd wrote: Hi! If firewire code doesn't build on clang correctly, have you filed a bug so it gets looked at before 10.0 is released? that's pretty broken code/behaviour. How I can do it correctly? Currently in src.conf: WITHOUT_CLANG=yes WITHOUT_CLANG_IS_CC=yes Need recompile world? System build from sources Jun 8. clang -- Jan 9. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
On 8/23/13 3:35 AM, David Chisnall wrote: On 23 Aug 2013, at 10:58, Bernhard Fröhlich de...@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. If src needs to move on, and it surely seems like it does, then ports needs to adapt. No offense to either team, but this is just common sense. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch to add AES intrinsics to gcc
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 de...@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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
patch to add AES intrinsics to gcc
In my work to get AES-NI performance in a better state and the fact that we haven't deprecated gcc yet, I have developed another patch to add the appropriate AES intrinstic headers to gcc. The patch is available at: https://people.freebsd.org/~jmg/gcc.aes.intrin.patch I did have to change the opth-gen.awk script, since it wouldn't let me use bit 31, and recent changes to gcc used up all the remaining bits. I also was unable to add the -mpclmul option because of running out of these bits. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
