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: 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; Well, we write rules and we brake them. ;-) Just say that we know we brake them but it's inevitable because... And go futher. I am not a developer, just a user, so I am not versed in all of the issues but I would REALLY like to see gcc moved to ports for 10.x In my opinion this just needs to happen, if ports break, we deal with that on a case by case basis. FreeBSD as a community made the decision to move to clang as a compiler, and moving gcc to ports enforces that decision, I prefer the rip the band aid off approach because it brings issues to light faster, and now people have real reasons to fix things. Now, I am aware that other architectures like ARM etc. need gcc in base for basic things like building kernel/world, because clang cant do this yet. Maybe this is over simplifying it a bit but can't we just modify scripts in some way to pull gcc from ports into base, for these platforms at build time? SVN *is* in base now (svnlite) From an outside look at this, it seems to me that we're holding back the amd64 platform just because the developer activity is a little more sparse than we would prefer on other platforms. Other platforms are important and they are needed, but those platforms are the ones that need patched up, they are the ones that need the band-aids implemented so that gcc still works for them. So I vote, let's not give ourselves the burden of lugging dead weight in base for another 5 years. (in 2017 do we still want to be worrying about gcc in base?) So in the name of progress, let's make a comfortable final resting place for gcc in our ports tree and look to clang for our future. Thoughts, Sam Fourman Jr. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: GCC withdraw
On 24 Aug 2013, at 11:30, Sam Fourman Jr. sfour...@gmail.com wrote: So I vote, let's not give ourselves the burden of lugging dead weight in base for another 5 years. (in 2017 do we still want to be worrying about gcc in base?) Perhaps more to the point, in 2017 do we want to be responsible for maintaining a fork of a 2007 release of gcc and libstdc++? David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: GCC withdraw
On 24 Aug 2013, at 12:51, Slawa Olhovchenkov s...@zxy.spb.ru wrote: Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Clang supports inline asm. If there is some specific inline asm syntax that clang does not recognise, then please will you point me to the relevant LLVM bug report and I will investigate it. David ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: GCC withdraw
In my opinion this just needs to happen, if ports break, we deal with that on a case by case basis. Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Well, in this case, you would just have the mplayer maintainer configure the port to use gcc for the i386 build of mplayer... problem solved -- Sam Fourman Jr. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: GCC withdraw
On Sat, Aug 24, 2013 at 12:11:16PM +, Sam Fourman Jr. wrote: In my opinion this just needs to happen, if ports break, we deal with that on a case by case basis. Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Well, in this case, you would just have the mplayer maintainer configure the port to use gcc for the i386 build of mplayer... problem solved Yes, I just edit Makefile. But this is point about ports builded by clang. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: GCC withdraw
On 8/24/13 7:19 PM, David Chisnall wrote: On 24 Aug 2013, at 11:30, Sam Fourman Jr. sfour...@gmail.com wrote: So I vote, let's not give ourselves the burden of lugging dead weight in base for another 5 years. (in 2017 do we still want to be worrying about gcc in base?) Perhaps more to the point, in 2017 do we want to be responsible for maintaining a fork of a 2007 release of gcc and libstdc++? The same work needs to be done no matter where it is.. there is no saving in moving it, and a lot of hassle.. leave the damned thing alone and be thankful that we have switched to clang by default! don't over-reach your successes. David ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: GCC withdraw
On Sat, Aug 24, 2013 at 01:10:46PM +0100, David Chisnall wrote: On 24 Aug 2013, at 12:51, Slawa Olhovchenkov s...@zxy.spb.ru wrote: Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Clang supports inline asm. If there is some specific inline asm syntax that clang does not recognise, then please will you point me to the relevant LLVM bug report and I will investigate it. Sorry, I don't know about clang/llvm bug reports, I just try to build mplayer with Win32 codecs support on FreeBSD-10/i386. And currenly (in rev r315041) building by clang disabled in ports tree. PS: Also, if FreeBSD ship clang why ship not full set of clang? For example, when I try to build llvm-lua not found sets of files: LLVMCompiler.cpp:25:30: error: llvm/LLVMContext.h: No such file or directory LLVMCompiler.cpp:26:31: error: llvm/DerivedTypes.h: No such file or directory LLVMCompiler.cpp:27:50: error: llvm/ExecutionEngine/ExecutionEngine.h: No such file or directory LLVMCompiler.cpp:28:25: error: llvm/Module.h: No such file or directory LLVMCompiler.cpp:29:30: error: llvm/PassManager.h: No such file or directory LLVMCompiler.cpp:30:36: error: llvm/Analysis/Verifier.h: No such file or directory LLVMCompiler.cpp:31:36: error: llvm/Target/TargetData.h: No such file or directory LLVMCompiler.cpp:32:39: error: llvm/Target/TargetMachine.h: No such file or directory LLVMCompiler.cpp:33:40: error: llvm/Target/TargetOptions.h: No such file or directory LLVMCompiler.cpp:34:36: error: llvm/Transforms/Scalar.h: No such file or directory LLVMCompiler.cpp:35:33: error: llvm/Transforms/IPO.h: No such file or directory LLVMCompiler.cpp:36:43: error: llvm/Transforms/Utils/Cloning.h: No such file or directory LLVMCompiler.cpp:37:36: error: llvm/Support/IRBuilder.h: No such file or directory LLVMCompiler.cpp:38:32: error: llvm/Support/Timer.h: No such file or directory LLVMCompiler.cpp:39:38: error: llvm/Support/CommandLine.h: No such file or directory ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: GCC withdraw
On Aug 24, 2013, at 6:11 AM, Sam Fourman Jr. wrote: In my opinion this just needs to happen, if ports break, we deal with that on a case by case basis. Oh, I remember. mplayer on i386 can't be builded witch clang -- clang don't understand inlined asm. Well, in this case, you would just have the mplayer maintainer configure the port to use gcc for the i386 build of mplayer... problem solved The problem is that there's a lot of cases in ports where this work needs to be done. That work is ongoing, but isn't done yet. The ports people have indicated that in the 10 time frame may be a bit optimistic... Warner ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: GCC withdraw
On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: GCC withdraw
On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote: On 24 Aug 2013, at 23:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And i found PR about clang and mplayer: ports/176272 This PR contains log with build error log. Please file clang bugs at http://llvm.org/bugs/ As if this is going to help. http://llvm.org/bugs/show_bug.cgi?id=8532 2 years, 9 month and counting. -- Steve ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
