Re: Fixed with r289221 (was: Re: CURRENT: build failure with clang 3.7.0)
On Tue, 13 Oct 2015 18:30:08 +0200 Dimitry Andric wrote: > On 10 Oct 2015, at 19:39, Dimitry Andric wrote: > > > > On 10 Oct 2015, at 18:12, O. Hartmann wrote: > > ... > >> Is there any chance that the failure of clang 3.7.0 with some AVX-equipted > >> Intel processors gets fixed soon? > > > > I reported the bug upstream, did number of bisections to drill down to > > the root cause (hopefully), and found an LLVM committer who has made a > > "quick hack" fix. This fix needs further review and test cases, though, > > before it is sane enough to commit upstream, and to import into our > > tree. This work will probably be done after the weekend. > > I committed the upstream fix in r289221. You should now be able to use > CPUTYPE safely again. Let me know if anything still breaks. :) > > -Dimitry > Everything is well and shiny again. Thank you very much. Oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Fixed with r289221 (was: Re: CURRENT: build failure with clang 3.7.0)
On 10 Oct 2015, at 19:39, Dimitry Andric wrote: > > On 10 Oct 2015, at 18:12, O. Hartmann wrote: > ... >> Is there any chance that the failure of clang 3.7.0 with some AVX-equipted >> Intel >> processors gets fixed soon? > > I reported the bug upstream, did number of bisections to drill down to > the root cause (hopefully), and found an LLVM committer who has made a > "quick hack" fix. This fix needs further review and test cases, though, > before it is sane enough to commit upstream, and to import into our > tree. This work will probably be done after the weekend. I committed the upstream fix in r289221. You should now be able to use CPUTYPE safely again. Let me know if anything still breaks. :) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: build failure with clang 3.7.0
On 10 Oct 2015, at 18:12, O. Hartmann wrote: ... > Is there any chance that the failure of clang 3.7.0 with some AVX-equipted > Intel > processors gets fixed soon? I reported the bug upstream, did number of bisections to drill down to the root cause (hopefully), and found an LLVM committer who has made a "quick hack" fix. This fix needs further review and test cases, though, before it is sane enough to commit upstream, and to import into our tree. This work will probably be done after the weekend. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: build failure with clang 3.7.0
Am Fri, 9 Oct 2015 23:07:18 +0200 Dimitry Andric schrieb: > On 07 Oct 2015, at 13:33, O. Hartmann wrote: > ... > > The buildworld error when building with CXXFLAGS+= -std=c++11 > > is > > then > > > > [...] > > cc -O2 -pipe -O3 -O3 -pipe -march=native -I. > > -I/usr/obj/usr/src/lib/ncurses/menu/../ncurses > > -I/usr/src/lib/ncurses/menu/../ncurses > > -I/usr/src/lib/ncurses/menu/../ncurses > > -I/usr/src/lib/ncurses/menu/../../../contrib/ncurses/include > > -I/usr/src/lib/ncurses/menu/../../../contrib/ncurses/ncurses -Wall -DNDEBUG > > -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menu/../../../contrib/ncurses/menu > > -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall > > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > > -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign > > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable > > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef > > -Qunused-arguments > > -c /usr/src/lib/ncurses/menu/../../../contrib/ncurses/menu/m_pad.c -o > > m_pad.o > > --- all_subdir_atf --- In file included > > from /usr/src/contrib/atf/atf-c++/detail/application.cpp:26: In file > > included > > from /usr/src/contrib/atf/atf-c++/detail/application.hpp:29: In file > > included > > from /usr/obj/usr/src/tmp/usr/include/c++/v1/ostream:138: In file included > > from /usr/obj/usr/src/tmp/usr/include/c++/v1/ios:216: In file included > > from /usr/obj/usr/src/tmp/usr/include/c++/v1/__locale:15: > > /usr/obj/usr/src/tmp/usr/include/c++/v1/string:1938:44: > > error: 'basic_string<_CharT, _Traits, _Allocator>' is missing exception > > specification > > 'noexcept(is_nothrow_copy_constructible::value)' [-Werror] > > basic_string<_CharT, _Traits, _Allocator>::basic_string(const > > allocator_type& > > __a) ^ /usr/obj/usr/src/tmp/usr/include/c++/v1/string:1326:40: note: > > previous > > declaration is here _LIBCPP_INLINE_VISIBILITY explicit basic_string(const > > allocator_type& __a) > > These particular -Werror warnings, when building with -std=c++11, should > now be fixed with r289082. Thanks for the report. > > -Dimitry > Is there any chance that the failure of clang 3.7.0 with some AVX-equipted Intel processors gets fixed soon? Regards, Oliver pgpBjsbNsUXFt.pgp Description: OpenPGP digital signature
Re: CURRENT: build failure with clang 3.7.0
On 07 Oct 2015, at 13:33, O. Hartmann wrote: ... > The buildworld error when building with CXXFLAGS+= -std=c++11 is > then > > [...] > cc -O2 -pipe -O3 -O3 -pipe -march=native -I. > -I/usr/obj/usr/src/lib/ncurses/menu/../ncurses > -I/usr/src/lib/ncurses/menu/../ncurses -I/usr/src/lib/ncurses/menu/../ncurses > -I/usr/src/lib/ncurses/menu/../../../contrib/ncurses/include > -I/usr/src/lib/ncurses/menu/../../../contrib/ncurses/ncurses -Wall -DNDEBUG > -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menu/../../../contrib/ncurses/menu > -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef > -Qunused-arguments > -c /usr/src/lib/ncurses/menu/../../../contrib/ncurses/menu/m_pad.c -o m_pad.o > --- all_subdir_atf --- In file included > from /usr/src/contrib/atf/atf-c++/detail/application.cpp:26: In file included > from /usr/src/contrib/atf/atf-c++/detail/application.hpp:29: In file included > from /usr/obj/usr/src/tmp/usr/include/c++/v1/ostream:138: In file included > from /usr/obj/usr/src/tmp/usr/include/c++/v1/ios:216: In file included > from /usr/obj/usr/src/tmp/usr/include/c++/v1/__locale:15: > /usr/obj/usr/src/tmp/usr/include/c++/v1/string:1938:44: > error: 'basic_string<_CharT, _Traits, _Allocator>' is missing exception > specification > 'noexcept(is_nothrow_copy_constructible::value)' [-Werror] > basic_string<_CharT, _Traits, _Allocator>::basic_string(const allocator_type& > __a) ^ /usr/obj/usr/src/tmp/usr/include/c++/v1/string:1326:40: note: previous > declaration is here _LIBCPP_INLINE_VISIBILITY explicit basic_string(const > allocator_type& __a) These particular -Werror warnings, when building with -std=c++11, should now be fixed with r289082. Thanks for the report. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: build failure with clang 3.7.0
On Wed, 07 Oct 2015 13:50:54 -0700 John Baldwin wrote: > On Wednesday, October 07, 2015 09:09:50 PM O. Hartmann wrote: > > Am Wed, 07 Oct 2015 11:03 -0700 > > John Baldwin schrieb: > > > > > On Wednesday, October 07, 2015 01:33:23 PM O. Hartmann wrote: > > > > On Wed, 7 Oct 2015 13:23:48 +0200 > > > > Dimitry Andric wrote: > > > > > > > > > On 07 Oct 2015, at 09:37, O. Hartmann > > > > > wrote: > > > > > > > > > > > > I hit on a box this nasty/sticky error when performing buildworld. > > > > > > > > > > > > /usr/src is on r288980 > > > > > ... > > > > > > --- ieee802_11_common.o --- > > > > > ... > > > > > > -c > > > > > > /usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/common/ieee802_11_common.c > > > > > > -o ieee802_11_common.o Cannot emit physreg copy instruction > > > > > > UNREACHABLE executed > > > > > > at > > > > > > /usr/src/lib/clang/libllvmx86codegen/../../../contrib/llvm/lib/Target/X86/X86InstrInfo.cpp:3935! > > > > > > > > > > Somebody else reported the same to me yesterday. This is an upstream > > > > > bug with AVX (which is still present in llvm trunk), so for now you > > > > > need to set your CPUTYPE to something that doesn't have AVX, or > > > > > simply unset your CPUTYPE. > > > > > > > > > > The bug has been reported upstream, and once there is a fix, I will > > > > > import it ASAP. > > > > > > > > > > -Dimitry > > > > > > > > > > > > > Funny, I have several other boxes, definitely having AVX aboard: > > > > > > > > [... from dmesg] > > > > Jul 29 07:05:52 freyja kernel: CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ > > > > 3.50GHz (3491.98-MHz K8-class CPU) > > > > Jul 29 07:05:52 freyja kernel: Origin="GenuineIntel" Id=0x306f2 > > > > Family=0x6 Model=0x3f Stepping=2 > > > > Jul 29 07:05:52 freyja kernel: > > > > Features=0xbfebfbff > > > > Jul 29 07:05:52 freyja kernel: > > > > Features2=0x7dfefbff > > > > Jul 29 07:05:52 freyja kernel: AMD > > > > Features=0x2c100800 > > > > Jul 29 07:05:52 freyja kernel: AMD Features2=0x21 > > > > Jul 29 07:05:52 freyja kernel: Structured Extended > > > > Features=0x37ab > > > > > > > > [...] > > > > > > > > which is a most recent Haswell XEON and builds world fine. My personal > > > > failing box is a i3-32XX, IvyBridge, but the IvyBridge E3-124XX XEON > > > > builds well. > > > > > > It's not about whether your CPU supports it, it is about whether or not > > > you have asked the compiler to use it. Normally by setting 'CPUTYPE' > > > in /etc/make.conf or the like. (I also was bitten by this yesterday on > > > my sandbridge laptop where I have 'CPUTYPE=corei7-avx' > > > in /etc/src.conf.) The workaround is to not set CPUTYPE (or set it to > > > something without AVX like just 'corei7'). > > > > > > > Hello. > > > > Well, I guess I understood the usage of CPUTYPE. Maybe I did not express > > myself in the clear, but I wanted to emphasize the fact that I'm using two > > CPUs supposedly of the same architectural design and if the AVX feature is > > indeed the culprit, then the question is why the one CPU compiles and the > > other not. I use on all machines the very same src.conf and make.conf > > except for the kernel name. So this would imply that on all boxes the very > > same feature set, identified by the CPU type, would be used. So far the > > theory. > > > > I did not check the expansion of CPUTYPE on both systems failing the > > buildworld, so maybe there is a slight difference there ... > > Are you using CPUTYPE=native? If so, the Haswell box might very well follow a > different chain of optimizations that avoids this edge case. > Yes, on all systems CPUTYPE is set according to: [...] # CPUTYPE?= native # CFLAGS+=-O3 -pipe COPTFLAGS+= -O3 -pipe # CXXFLAGS+= -std=c++11 [...] My point is: My Haswell-based boxes (XEON E5-16XX, Laptop i3-4200M) and a XEON E3-12XX Ivy Bridge work/buildworld well, while customer type CPUs, i3-32XX and i5-3470 fail. So why is this specific XEON Ivy Bridge working then? I think this question is a kind of academic and a bit useless, I have no access to that XEON Ivy Bridge box so I can not check the exact CPU model. I nailed myself down to the AVX issue. I forgot that Intel might have introduced severe architectural differences or it is a bug fixed in later emitted CPU type ... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: build failure with clang 3.7.0
On Wednesday, October 07, 2015 09:09:50 PM O. Hartmann wrote: > Am Wed, 07 Oct 2015 11:03 -0700 > John Baldwin schrieb: > > > On Wednesday, October 07, 2015 01:33:23 PM O. Hartmann wrote: > > > On Wed, 7 Oct 2015 13:23:48 +0200 > > > Dimitry Andric wrote: > > > > > > > On 07 Oct 2015, at 09:37, O. Hartmann > > > > wrote: > > > > > > > > > > I hit on a box this nasty/sticky error when performing buildworld. > > > > > > > > > > /usr/src is on r288980 > > > > ... > > > > > --- ieee802_11_common.o --- > > > > ... > > > > > -c > > > > > /usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/common/ieee802_11_common.c > > > > > -o ieee802_11_common.o Cannot emit physreg copy instruction > > > > > UNREACHABLE > > > > > executed > > > > > at > > > > > /usr/src/lib/clang/libllvmx86codegen/../../../contrib/llvm/lib/Target/X86/X86InstrInfo.cpp:3935! > > > > > > > > Somebody else reported the same to me yesterday. This is an upstream > > > > bug with AVX (which is still present in llvm trunk), so for now you need > > > > to set your CPUTYPE to something that doesn't have AVX, or simply unset > > > > your CPUTYPE. > > > > > > > > The bug has been reported upstream, and once there is a fix, I will > > > > import it ASAP. > > > > > > > > -Dimitry > > > > > > > > > > Funny, I have several other boxes, definitely having AVX aboard: > > > > > > [... from dmesg] > > > Jul 29 07:05:52 freyja kernel: CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ > > > 3.50GHz > > > (3491.98-MHz K8-class CPU) > > > Jul 29 07:05:52 freyja kernel: Origin="GenuineIntel" Id=0x306f2 > > > Family=0x6 > > > Model=0x3f Stepping=2 > > > Jul 29 07:05:52 freyja kernel: > > > Features=0xbfebfbff > > > Jul 29 07:05:52 freyja kernel: > > > Features2=0x7dfefbff > > > Jul 29 07:05:52 freyja kernel: AMD > > > Features=0x2c100800 > > > Jul 29 07:05:52 freyja kernel: AMD Features2=0x21 > > > Jul 29 07:05:52 freyja kernel: Structured Extended > > > Features=0x37ab > > > > > > [...] > > > > > > which is a most recent Haswell XEON and builds world fine. My personal > > > failing > > > box is a i3-32XX, IvyBridge, but the IvyBridge E3-124XX XEON builds well. > > > > It's not about whether your CPU supports it, it is about whether or not you > > have > > asked the compiler to use it. Normally by setting 'CPUTYPE' in > > /etc/make.conf > > or the like. (I also was bitten by this yesterday on my sandbridge laptop > > where I have 'CPUTYPE=corei7-avx' in /etc/src.conf.) The workaround is to > > not > > set CPUTYPE (or set it to something without AVX like just 'corei7'). > > > > Hello. > > Well, I guess I understood the usage of CPUTYPE. Maybe I did not express > myself in the > clear, but I wanted to emphasize the fact that I'm using two CPUs supposedly > of the same > architectural design and if the AVX feature is indeed the culprit, then the > question is > why the one CPU compiles and the other not. I use on all machines the very > same src.conf > and make.conf except for the kernel name. So this would imply that on all > boxes the very > same feature set, identified by the CPU type, would be used. So far the > theory. > > I did not check the expansion of CPUTYPE on both systems failing the > buildworld, so maybe > there is a slight difference there ... Are you using CPUTYPE=native? If so, the Haswell box might very well follow a different chain of optimizations that avoids this edge case. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: build failure with clang 3.7.0
Am Wed, 07 Oct 2015 11:03 -0700 John Baldwin schrieb: > On Wednesday, October 07, 2015 01:33:23 PM O. Hartmann wrote: > > On Wed, 7 Oct 2015 13:23:48 +0200 > > Dimitry Andric wrote: > > > > > On 07 Oct 2015, at 09:37, O. Hartmann wrote: > > > > > > > > I hit on a box this nasty/sticky error when performing buildworld. > > > > > > > > /usr/src is on r288980 > > > ... > > > > --- ieee802_11_common.o --- > > > ... > > > > -c > > > > /usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/common/ieee802_11_common.c > > > > -o ieee802_11_common.o Cannot emit physreg copy instruction UNREACHABLE > > > > executed > > > > at > > > > /usr/src/lib/clang/libllvmx86codegen/../../../contrib/llvm/lib/Target/X86/X86InstrInfo.cpp:3935! > > > > > > Somebody else reported the same to me yesterday. This is an upstream > > > bug with AVX (which is still present in llvm trunk), so for now you need > > > to set your CPUTYPE to something that doesn't have AVX, or simply unset > > > your CPUTYPE. > > > > > > The bug has been reported upstream, and once there is a fix, I will > > > import it ASAP. > > > > > > -Dimitry > > > > > > > Funny, I have several other boxes, definitely having AVX aboard: > > > > [... from dmesg] > > Jul 29 07:05:52 freyja kernel: CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ > > 3.50GHz > > (3491.98-MHz K8-class CPU) > > Jul 29 07:05:52 freyja kernel: Origin="GenuineIntel" Id=0x306f2 Family=0x6 > > Model=0x3f Stepping=2 > > Jul 29 07:05:52 freyja kernel: > > Features=0xbfebfbff > > Jul 29 07:05:52 freyja kernel: > > Features2=0x7dfefbff > > Jul 29 07:05:52 freyja kernel: AMD > > Features=0x2c100800 > > Jul 29 07:05:52 freyja kernel: AMD Features2=0x21 > > Jul 29 07:05:52 freyja kernel: Structured Extended > > Features=0x37ab > > > > [...] > > > > which is a most recent Haswell XEON and builds world fine. My personal > > failing > > box is a i3-32XX, IvyBridge, but the IvyBridge E3-124XX XEON builds well. > > It's not about whether your CPU supports it, it is about whether or not you > have > asked the compiler to use it. Normally by setting 'CPUTYPE' in /etc/make.conf > or the like. (I also was bitten by this yesterday on my sandbridge laptop > where I have 'CPUTYPE=corei7-avx' in /etc/src.conf.) The workaround is to not > set CPUTYPE (or set it to something without AVX like just 'corei7'). > Hello. Well, I guess I understood the usage of CPUTYPE. Maybe I did not express myself in the clear, but I wanted to emphasize the fact that I'm using two CPUs supposedly of the same architectural design and if the AVX feature is indeed the culprit, then the question is why the one CPU compiles and the other not. I use on all machines the very same src.conf and make.conf except for the kernel name. So this would imply that on all boxes the very same feature set, identified by the CPU type, would be used. So far the theory. I did not check the expansion of CPUTYPE on both systems failing the buildworld, so maybe there is a slight difference there ... Oliver pgpSHGObdXCOM.pgp Description: OpenPGP digital signature
Re: CURRENT: build failure with clang 3.7.0
On Wednesday, October 07, 2015 01:33:23 PM O. Hartmann wrote: > On Wed, 7 Oct 2015 13:23:48 +0200 > Dimitry Andric wrote: > > > On 07 Oct 2015, at 09:37, O. Hartmann wrote: > > > > > > I hit on a box this nasty/sticky error when performing buildworld. > > > > > > /usr/src is on r288980 > > ... > > > --- ieee802_11_common.o --- > > ... > > > -c > > > /usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/common/ieee802_11_common.c > > > -o ieee802_11_common.o Cannot emit physreg copy instruction UNREACHABLE > > > executed > > > at > > > /usr/src/lib/clang/libllvmx86codegen/../../../contrib/llvm/lib/Target/X86/X86InstrInfo.cpp:3935! > > > > Somebody else reported the same to me yesterday. This is an upstream > > bug with AVX (which is still present in llvm trunk), so for now you need > > to set your CPUTYPE to something that doesn't have AVX, or simply unset > > your CPUTYPE. > > > > The bug has been reported upstream, and once there is a fix, I will > > import it ASAP. > > > > -Dimitry > > > > Funny, I have several other boxes, definitely having AVX aboard: > > [... from dmesg] > Jul 29 07:05:52 freyja kernel: CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz > (3491.98-MHz K8-class CPU) > Jul 29 07:05:52 freyja kernel: Origin="GenuineIntel" Id=0x306f2 Family=0x6 > Model=0x3f Stepping=2 > Jul 29 07:05:52 freyja kernel: > Features=0xbfebfbff > Jul 29 07:05:52 freyja kernel: > Features2=0x7dfefbff > Jul 29 07:05:52 freyja kernel: AMD > Features=0x2c100800 > Jul 29 07:05:52 freyja kernel: AMD Features2=0x21 > Jul 29 07:05:52 freyja kernel: Structured Extended > Features=0x37ab > > [...] > > which is a most recent Haswell XEON and builds world fine. My personal failing > box is a i3-32XX, IvyBridge, but the IvyBridge E3-124XX XEON builds well. It's not about whether your CPU supports it, it is about whether or not you have asked the compiler to use it. Normally by setting 'CPUTYPE' in /etc/make.conf or the like. (I also was bitten by this yesterday on my sandbridge laptop where I have 'CPUTYPE=corei7-avx' in /etc/src.conf.) The workaround is to not set CPUTYPE (or set it to something without AVX like just 'corei7'). -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: build failure with clang 3.7.0
On Wed, 7 Oct 2015 13:23:48 +0200 Dimitry Andric wrote: > On 07 Oct 2015, at 09:37, O. Hartmann wrote: > > > > I hit on a box this nasty/sticky error when performing buildworld. > > > > /usr/src is on r288980 > ... > > --- ieee802_11_common.o --- > ... > > -c > > /usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/common/ieee802_11_common.c > > -o ieee802_11_common.o Cannot emit physreg copy instruction UNREACHABLE > > executed > > at > > /usr/src/lib/clang/libllvmx86codegen/../../../contrib/llvm/lib/Target/X86/X86InstrInfo.cpp:3935! > > Somebody else reported the same to me yesterday. This is an upstream > bug with AVX (which is still present in llvm trunk), so for now you need > to set your CPUTYPE to something that doesn't have AVX, or simply unset > your CPUTYPE. > > The bug has been reported upstream, and once there is a fix, I will > import it ASAP. > > -Dimitry > When I allow to build with CXXFLAGS+= -std=c++11 set in /etx/src.conf, I get the below shown error. Funny, I have several other boxes, definitely having AVX aboard: [... from dmesg] Jul 29 07:05:52 freyja kernel: CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (3491.98-MHz K8-class CPU) Jul 29 07:05:52 freyja kernel: Origin="GenuineIntel" Id=0x306f2 Family=0x6 Model=0x3f Stepping=2 Jul 29 07:05:52 freyja kernel: Features=0xbfebfbff Jul 29 07:05:52 freyja kernel: Features2=0x7dfefbff Jul 29 07:05:52 freyja kernel: AMD Features=0x2c100800 Jul 29 07:05:52 freyja kernel: AMD Features2=0x21 Jul 29 07:05:52 freyja kernel: Structured Extended Features=0x37ab [...] which is a most recent Haswell XEON and builds world fine. My personal failing box is a i3-32XX, IvyBridge, but the IvyBridge E3-124XX XEON builds well. The output shown below and the error I reported is from this hardware: CPU: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (3192.81-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 Features=0xbfebfbff Features2=0x7fbae3ff AMD Features=0x28100800 AMD Features2=0x1 Structured Extended Features=0x281 XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics The buildworld error when building with CXXFLAGS+= -std=c++11 is then [...] cc -O2 -pipe -O3 -O3 -pipe -march=native -I. -I/usr/obj/usr/src/lib/ncurses/menu/../ncurses -I/usr/src/lib/ncurses/menu/../ncurses -I/usr/src/lib/ncurses/menu/../ncurses -I/usr/src/lib/ncurses/menu/../../../contrib/ncurses/include -I/usr/src/lib/ncurses/menu/../../../contrib/ncurses/ncurses -Wall -DNDEBUG -DHAVE_CONFIG_H -I/usr/src/lib/ncurses/menu/../../../contrib/ncurses/menu -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c /usr/src/lib/ncurses/menu/../../../contrib/ncurses/menu/m_pad.c -o m_pad.o --- all_subdir_atf --- In file included from /usr/src/contrib/atf/atf-c++/detail/application.cpp:26: In file included from /usr/src/contrib/atf/atf-c++/detail/application.hpp:29: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/ostream:138: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/ios:216: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/__locale:15: /usr/obj/usr/src/tmp/usr/include/c++/v1/string:1938:44: error: 'basic_string<_CharT, _Traits, _Allocator>' is missing exception specification 'noexcept(is_nothrow_copy_constructible::value)' [-Werror] basic_string<_CharT, _Traits, _Allocator>::basic_string(const allocator_type& __a) ^ /usr/obj/usr/src/tmp/usr/include/c++/v1/string:1326:40: note: previous declaration is here _LIBCPP_INLINE_VISIBILITY explicit basic_string(const allocator_type& __a) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CURRENT: build failure with clang 3.7.0
On 07 Oct 2015, at 09:37, O. Hartmann wrote: > > I hit on a box this nasty/sticky error when performing buildworld. > > /usr/src is on r288980 ... > --- ieee802_11_common.o --- ... > -c > /usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/common/ieee802_11_common.c > -o ieee802_11_common.o Cannot emit physreg copy instruction UNREACHABLE > executed > at > /usr/src/lib/clang/libllvmx86codegen/../../../contrib/llvm/lib/Target/X86/X86InstrInfo.cpp:3935! Somebody else reported the same to me yesterday. This is an upstream bug with AVX (which is still present in llvm trunk), so for now you need to set your CPUTYPE to something that doesn't have AVX, or simply unset your CPUTYPE. The bug has been reported upstream, and once there is a fix, I will import it ASAP. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: build failure with clang 3.7.0
> On Oct 7, 2015, at 00:37, O. Hartmann wrote: > > I hit on a box this nasty/sticky error when performing buildworld. … > By the way, it seems that etc/rc.d/tests doesn't get deleted via "make > delete-old”. make delete-old only cleans up things installed to the system, not things in your source tree. Feel free to rm -Rf the path. > The failure is shown below. > > My /etc/src.conf is this: … > -o ieee802_11_common.o Cannot emit physreg copy instruction UNREACHABLE > executed > at > /usr/src/lib/clang/libllvmx86codegen/../../../contrib/llvm/lib/Target/X86/X86InstrInfo.cpp:3935! > cc: error: unable to execute command: Abort trap cc: error: clang frontend > command failed due to signal (use -v to see invocation) FreeBSD clang version > 3.7.0 (tags/RELEASE_370/final 246257) 20150906 Target: > x86_64-unknown-freebsd11.0 Thread model: posix cc: note: diagnostic msg: > PLEASE > submit a bug report to https://bugs.freebsd.org/submit/ and include the crash > backtrace, preprocessed source, and associated run script. --- usr.bin.all__D > --- --- ex_abbrev.o --- cc -O2 -pipe -O3 -O3 -pipe -march=native > -D__REGEX_PRIVATE -I/usr/src/usr.bin/vi > -I/usr/src/usr.bin/vi/../../contrib/nvi > -I/usr/src/usr.bin/vi/../../contrib/nvi/regex -DUSE_WIDECHAR -DUSE_ICONV > -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function > -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum > -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments > -c /usr/src/usr.bin/vi/../../contrib/nvi/ex/ex_abbrev.c -o ex_abbrev.o --- > usr.sbin.all__D --- cc: note: diagnostic msg: > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > cc: note: diagnostic msg: /tmp/ieee802_11_common-b7c29f.c > cc: note: diagnostic msg: /tmp/ieee802_11_common-b7c29f.sh > cc: note: diagnostic msg: > > > *** [ieee802_11_common.o] Error code 254 > > make[5]: stopped in /usr/src/usr.sbin/wpa/wpa_supplicant > 1 error As the message says, please file a bug with all the requested details. FWIW, I haven’t run into that error with my system from that directory with clang 3.7.0/amd64, but I don’t build with -O3 by default (I learned my lesson about using -O after playing around with Gentoo Linux several years ago). Cheers, -NGie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"