1 |
Am 21.07.2011 15:10, schrieb William Kenworthy: |
2 |
> On Thu, 2011-07-21 at 11:21 +0200, Florian Philipp wrote: |
3 |
>> Am 21.07.2011 10:57, schrieb Pandu Poluan: |
4 |
>>> -original message- |
5 |
>>> Subject: Re: [gentoo-user] New computer and Gentoo |
6 |
>>> From: Bill Kenworthy <billk@×××××××××.au> |
7 |
>>> Date: 2011-07-21 12:54 |
8 |
>>> |
9 |
>>>> On Thu, 2011-07-21 at 06:26 +0100, Mick wrote: |
10 |
>> [...] |
11 |
>>>> Ive just stumbled on something weird with march=native: |
12 |
>>>> |
13 |
> |
14 |
>> |
15 |
>> I'd like to see a reference for this claim. -march=native doesn't do |
16 |
>> more than set -march=core2 and some other optimizations for cache size |
17 |
>> etc. This should be no more troublesome than mixing code compiled with |
18 |
> |
19 |
> unfortunately this is now my main machine so I cant fiddle too much with |
20 |
> it! It would mean going back to the E4600 and comparing march=prescott, |
21 |
> march=native then fitting the E6600 and checking march=native and |
22 |
> march=core2. What I cant find is a reference to how it works out what |
23 |
> native is? - lookup-table, checking the flags in /proc/cpuinfo or what? |
24 |
> |
25 |
[...] |
26 |
|
27 |
Use the source, Luke. Take a look at the gcc sources in your distfiles |
28 |
directory. It is in the gcc package, file |
29 |
"./gcc/config/i386/driver-i386.c" (found via grep for "\<native" and |
30 |
then grep for "host_detect_local_cpu"). It is surprisingly understandable. |
31 |
|
32 |
Most of the detection is done by introspecting CPUID. Most importantly, |
33 |
the CPU family is deducted from the found capabilities, not vice versa. |
34 |
Therefore there is no chance that a CPU that claims to be, let's say, a |
35 |
Core2, but lacks some capabilities, ends up being classified as a Core2 |
36 |
(unless, of course, if the GCC guys get their switch-case logic wrong). |
37 |
|
38 |
Regards, |
39 |
Florian Philipp |