Re: CURRENT: build failure with clang 3.7.0

On Wed, 07 Oct 2015 13:50:54 -0700
John Baldwin <jhb_at_freebsd.org> wrote:

> On Wednesday, October 07, 2015 09:09:50 PM O. Hartmann wrote:
> > Am Wed, 07 Oct 2015 11:03 -0700
> > John Baldwin <jhb_at_freebsd.org> schrieb:
> > 
> > > On Wednesday, October 07, 2015 01:33:23 PM O. Hartmann wrote:
> > > > On Wed, 7 Oct 2015 13:23:48 +0200
> > > > Dimitry Andric <dim_at_FreeBSD.org> wrote:
> > > > 
> > > > > On 07 Oct 2015, at 09:37, O. Hartmann <ohartman_at_zedat.fu-berlin.de>
> > > > > 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 _at_
> > > > 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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > Jul 29 07:05:52 freyja kernel:
> > > > Features2=0x7dfefbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
> > > > Jul 29 07:05:52 freyja kernel: AMD
> > > > Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
> > > > Jul 29 07:05:52 freyja kernel: AMD Features2=0x21<LAHF,ABM>
> > > > Jul 29 07:05:52 freyja kernel: Structured Extended
> > > > Features=0x37ab<FSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,NFPUSG>
> > > > 
> > > > [...]
> > > > 
> > > > 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 ...