Re: Fixed with r289221 (was: Re: CURRENT: build failure with clang 3.7.0)

[O. Hartmann]

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)

[Dimitry Andric]

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

[O. Hartmann]

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

[Dimitry Andric]

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

[Dimitry Andric]

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

[O. Hartmann]

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 

Re: CURRENT: build failure with clang 3.7.0

[John Baldwin]

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"

CURRENT: build failure with clang 3.7.0

[O. Hartmann]

I hit on a box this nasty/sticky error when performing buildworld.

/usr/src is on r288980

svn status gives

#: [src] svn st
?   .snap
?   .sujournal
?   etc/rc.d/tests
?   sys/amd64/conf/HAGENVONTRONJE

By the way, it seems that etc/rc.d/tests doesn't get deleted via "make
delete-old".

The failure is shown below.

My /etc/src.conf is this:

#
CPUTYPE?=   native
#
CFLAGS+=-O3 -pipe
COPTFLAGS+= -O3 -pipe
#
#CXXFLAGS+= -std=c++11
#
WITH_CLANG_FULL=YES
WITH_CLANG_EXTRAS=  YES
WITH_LLDB=  YES
#
WITH_IDEA=  YES
#
#WITH_BSD_GREP= YES
#
#WITH_OFED= YES
WITH_NAND=  YES
#WITH_CTF=  YES
#
WITH_SVN=   YES
#
MALLOC_PRODUCTION=  YES
#
#WITHOUT_DEBUG_FILES=   YES
#
PORTS_MODULES=
PORTS_MODULES+= emulators/virtualbox-ose-kmod

I use this /etc/src.conf also on other machines, but with
CXXFLAGS+= -std=c++11
enabled. It works on two out of three, the third (not the reported one here)
fails in atf-c++, I will report later when I have access to the box.
The strange thing on that is that I use the very specific non-vanilla src.conf
on several systems and they work and do well, even with CURRENT as discussed
here, but there are problems I can not fathom since source tree and compilation
flags are the same and even the startig revision of the building machine's
CURRENT is the same.

regards,

oliver

[...]

--- ieee802_11_common.o ---
cc  -O2 -pipe -O3 -O3 -pipe -march=native
-I/usr/src/usr.sbin/wpa/wpa_supplicant
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//hostapd
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/drivers
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/utils
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/wps
-DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DCONFIG_BACKEND_FILE
-DCONFIG_DEBUG_SYSLOG  -DCONFIG_DRIVER_BSD  -DCONFIG_DRIVER_NDIS
-DCONFIG_DRIVER_WIRED  -DCONFIG_GAS  -DCONFIG_HS20  -DCONFIG_IEEE80211R
-DCONFIG_INTERWORKING  -DCONFIG_PEERKEY  -DCONFIG_PRIVSEP  -DCONFIG_SMARTCARD
-DCONFIG_TERMINATE_ONLASTIF  -DCONFIG_TLS=openssl  -DCONFIG_WPS  -DCONFIG_WPS2
-DCONFIG_WPS_UPNP  -DPKCS12_FUNCS  -DEAP_GTC  -DEAP_LEAP  -DEAP_MD5
-DEAP_MSCHAPv2  -DEAP_OTP  -DEAP_PEAP  -DEAP_PSK  -DEAP_TLS  -DEAP_TTLS
-DIEEE8021X_EAPOL -DCONFIG_SHA256 -DEAP_TLS_OPENSSL
-I/usr/src/usr.sbin/wpa/wpa_supplicant
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//hostapd
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/common
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/crypto
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/drivers
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/l2_packet
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/utils
-I/usr/src/usr.sbin/wpa/wpa_supplicant/../../../contrib/wpa//src/wps
-DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -std=gnu99
-fstack-protector-strong   -Qunused-arguments
-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!
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: 

Re: CURRENT: build failure with clang 3.7.0

[NGie Cooper]

> 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"

Re: CURRENT: build failure with clang 3.7.0

[O. Hartmann]

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

[O. Hartmann]

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

[Dimitry Andric]

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

[John Baldwin]

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"