intel i5 - core? or core2?

Domagoj S. rank1seeker at
Mon Aug 23 13:39:39 UTC 2010

On Sat, Aug 21, 2010 at 6:25 PM, Anonymous <swell.k at> wrote:
> "Domagoj S." <rank1seeker at> writes:
>> 8.1 RELEASE  32bit
>> # gcc --version
>> gcc (GCC) 4.2.1 20070719  [FreeBSD]
>> As per:
>> core2 is supported
> It's not! `core' and `core2' for -mtune/-march introduced since gcc43.

I've been confusing FreeBSD's 'CPUTYPE' with gcc's '-march='

> BTW, while clang in base (on /head) supports -march=core2 it's still
> better to stick to -march=native, e.g. on my box
>  CPU: Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz (3177.07-MHz K8-class CPU)
> `native' on clang implies `penryn', not a `core2'. While `native' on
> gcc45 implies `core2' + extra cflags[1].
> [1] -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144

I see..., so I should always go against FBSD devs and ensure that
gcc's arg '-march=' is always populated by value 'native'?
That is, gcc should alone determine CPU? Not a human user and then
setting "discovered" CPU type in CPUTYPE?

> You can populate MACHINE_CPU directly, e.g.
>  CPUTYPE ?= native
>  MACHINE_CPU != echo ${MACHINE_ARCH}; ${CC} -E -dM -v -march=${CPUTYPE} - </dev/null 2>&1 \
>        | awk '/SSE|MMX/ && !/MATH/ { FS="__"; gsub("_",".",$$2); print tolower($$2) }'
>  MACHINE_CPU += i486 i586 i686
> Note sure how well it'll work for cross-arch compilation, though.

Setting CPUTYPE will populate MACHINE_CPU.
Then I can ensure gcc's arg '-march=native' by setting:
CFLAGS=-O2 -pipe -march=native

But CPUTYPE will also append it's own '-march=', so to stop it:

I've also saw recommendation to add:
COPTFLAGS=-O2 -pipe -march=native

But I didn't see that CPUTYPE, has ever set COPTFLAGS?

So now I am totally confused with all this options?
What is the right way?

>> CPUTYPE?=native is nowhere mentioned "in FreeBSD"
> That cruft in was written in pre-gcc4 days, i.e. when it
> didn't support -march=native. Besides, if not maintained to accommodate
> for newer gcc's from ports those aliases are more harmful than
> useful. And not much code uses MACHINE_CPU in base anyway, only
> libcrypto and libz.

So if I decide to use a latest compiler from ports, I MUST avoid usage

Finally, should I use latest gcc compiler from ports, to build world &
kernel, with:
CFLAGS=-O2 -pipe -march=native
COPTFLAGS=-O2 -pipe -march=native

And a, regarding speed, please in percentage and taking regular binary
install from .iso, as a speed of value 100%, to be compared against.
What kind of gain, is compared to compilation from source:
a) Without any variables set in /etc/make.conf or passed on CMD
b) Only CPUTYPE var set, as officially recommended
c) Appending CFLAGS, NO_CPU_CFLAGS ... to b)
d) Using latest gcc from ports

More information about the freebsd-hackers mailing list