From owner-freebsd-toolchain@FreeBSD.ORG  Tue Nov  8 21:04:20 2011
Return-Path: <owner-freebsd-toolchain@FreeBSD.ORG>
Delivered-To: freebsd-toolchain@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 1233)
	id EB71D1065674; Tue,  8 Nov 2011 21:04:20 +0000 (UTC)
Date: Tue, 8 Nov 2011 21:04:20 +0000
From: Alexander Best <arundel@freebsd.org>
To: Roman Divacky <rdivacky@freebsd.org>
Message-ID: <20111108210420.GA37161@freebsd.org>
References: <20111108002556.GA91218@freebsd.org> <4EB8E07B.5070908@FreeBSD.org>
	<20111108153856.GA90966@freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20111108153856.GA90966@freebsd.org>
Cc: freebsd-toolchain@freebsd.org, Dimitry Andric <dim@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
	<freebsd-toolchain.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>, 
	<mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>, 
	<mailto:freebsd-toolchain-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2011 21:04:21 -0000

On Tue Nov  8 11, Roman Divacky wrote:
> On Tue, Nov 08, 2011 at 08:55:39AM +0100, 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
> 
> Yes, we definitely should aim for fixing the problems instead of working
> around them.
> 
> This way both clang and freebsd benefits.

for me -march=native reports:

otaku% gcc -march=native -E -v - </dev/null
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.2 20070831 prerelease [FreeBSD]
 /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=nocona -mtune=generic
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/gcc/4.2
 /usr/include
End of search list.
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "<stdin>"

where instead of nocona, core2 would have been the better choice:

[1.000000] CPU: Intel(R) Pentium(R) Dual  CPU  E2160  @ 1.80GHz (1800.00-MHz K8-class CPU)
[1.000000]   Origin = "GenuineIntel"  Id = 0x6fd  Family = 6  Model = f  Stepping = 13
[1.000000]   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>
[1.000000]   Features2=0xe39d<SSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM>
[1.000000]   AMD Features=0x20100800<SYSCALL,NX,LM>
[1.000000]   AMD Features2=0x1<LAHF>
[1.000000]   TSC: P-state invariant, performance statistics

cheers.
alex

> 
> roman