From owner-freebsd-current@freebsd.org Thu Oct 8 06:08:15 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CE429D1768 for ; Thu, 8 Oct 2015 06:08:15 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECB95B64; Thu, 8 Oct 2015 06:08:14 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1Zk4N9-001y4V-Sb>; Thu, 08 Oct 2015 08:08:11 +0200 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=freyja.zeit4.iv.bundesimmobilien.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1Zk4N9-0045sl-KR>; Thu, 08 Oct 2015 08:08:11 +0200 Date: Thu, 8 Oct 2015 08:08:06 +0200 From: "O. Hartmann" To: John Baldwin Cc: freebsd-current@freebsd.org, Dimitry Andric Subject: Re: CURRENT: build failure with clang 3.7.0 Message-ID: <20151008080806.157e3480@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <2790993.pgulpShlNy@ralph.baldwin.cx> References: <20151007093727.0db8e2e6@freyja.zeit4.iv.bundesimmobilien.de> <10633363.fQY0fDW1VU@ralph.baldwin.cx> <20151007210950.60474f36.ohartman@zedat.fu-berlin.de> <2790993.pgulpShlNy@ralph.baldwin.cx> Organization: FU Berlin X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 87.138.105.249 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 06:08:15 -0000 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 ...