public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Florian Philipp <lists@binarywings.net>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] New computer and Gentoo
Date: Thu, 21 Jul 2011 16:05:36 +0200	[thread overview]
Message-ID: <4E283230.5030801@binarywings.net> (raw)
In-Reply-To: <1311253852.29724.19.camel@moriah>

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

Am 21.07.2011 15:10, schrieb William Kenworthy:
> On Thu, 2011-07-21 at 11:21 +0200, Florian Philipp wrote:
>> Am 21.07.2011 10:57, schrieb Pandu Poluan:
>>> -original message-
>>> Subject: Re: [gentoo-user] New computer and Gentoo
>>> From: Bill Kenworthy <billk@iinet.net.au>
>>> Date: 2011-07-21 12:54
>>>
>>>> On Thu, 2011-07-21 at 06:26 +0100, Mick wrote:
>> [...]
>>>> Ive just stumbled on something weird with march=native:
>>>>
> 
>>
>> I'd like to see a reference for this claim. -march=native doesn't do
>> more than set -march=core2 and some other optimizations for cache size
>> etc. This should be no more troublesome than mixing code compiled with
> 
> unfortunately this is now my main machine so I cant fiddle too much with
> it!  It would mean going back to the E4600 and comparing march=prescott,
> march=native then fitting the E6600 and checking march=native and
> march=core2.  What I cant find is a reference to how it works out what
> native is? - lookup-table, checking the flags in /proc/cpuinfo or what?
> 
[...]

Use the source, Luke. Take a look at the gcc sources in your distfiles
directory. It is in the gcc package, file
"./gcc/config/i386/driver-i386.c" (found via grep for "\<native" and
then grep for "host_detect_local_cpu"). It is surprisingly understandable.

Most of the detection is done by introspecting CPUID. Most importantly,
the CPU family is deducted from the found capabilities, not vice versa.
Therefore there is no chance that a CPU that claims to be, let's say, a
Core2, but lacks some capabilities, ends up being classified as a Core2
(unless, of course, if the GCC guys get their switch-case logic wrong).

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2011-07-21 14:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-21  8:57 [gentoo-user] New computer and Gentoo Pandu Poluan
2011-07-21  9:21 ` Florian Philipp
2011-07-21  9:52   ` Pandu Poluan
2011-07-21  9:56   ` Florian Philipp
2011-07-21 13:10   ` William Kenworthy
2011-07-21 14:05     ` Florian Philipp [this message]
2011-07-23 13:40       ` Stroller
  -- strict thread matches above, loose matches on Subject: below --
2011-07-21  2:23 CJoeB
2011-07-21  2:29 ` Adam Carter
2011-07-21  5:26   ` Mick
2011-07-21  5:54     ` Bill Kenworthy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E283230.5030801@binarywings.net \
    --to=lists@binarywings.net \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox