From owner-freebsd-toolchain@FreeBSD.ORG Sat Nov 19 23:53:46 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 50F6D106566C; Sat, 19 Nov 2011 23:53:46 +0000 (UTC) Date: Sat, 19 Nov 2011 23:53:46 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20111119235346.GA57138@freebsd.org> References: <20111108002556.GA91218@freebsd.org> <4EB8E07B.5070908@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB8E07B.5070908@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 23:53:46 -0000 On Tue Nov 8 11, Dimitry Andric wrote: > On 2011-11-08 01:25, Alexander Best wrote: > > i've seen dozens of issues, where people set CPUTYPE=native. although this > > works in a lot of cases, it doesn't in others. why don't we simply add > > something like > > > > . if ${CPUTYPE} == "native" > > . error "bla" > > . endif > > > > in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is > > known to cause problems. > > What does this solve? Don't you think it is better to try to fix the > actual problems? Some people like being able to optimize for their > specific CPU, however much you can shoot yourself in the foot with it. just wanted to report that i found an issue with CPUTYPE "native". simply do the following on amd64 (i tested this on ref9-amd64.freebsd.org): make.conf: CPUTYPE ?= native CFLAGS = -O2 -pipe -fno-strict-aliasing -funroll-loops -fno-builtin KERNCONF = GENERIC now 'make buildworld' and enjoy the signal 11. ;) setting CPUTYPE to nocona or commenting it out lets 'mak buildworld' succeed. cheers. alex there's a problem report for this already: http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/149712 > > I haven't seen any consistent bug reports yet, just a lot of complaints > that indicate a rather high probability of PEBKAC. > > And just to counter the nay-saying, I compiled a number of boxes with > clang -march=native (mostly of the Xeon/i7 variant) and I haven't seen > any problems at all.