1 |
Am 21.07.2011 11:21, schrieb Florian Philipp: |
2 |
> Am 21.07.2011 10:57, schrieb Pandu Poluan: |
3 |
>> -original message- |
4 |
>> Subject: Re: [gentoo-user] New computer and Gentoo |
5 |
>> From: Bill Kenworthy <billk@×××××××××.au> |
6 |
>> Date: 2011-07-21 12:54 |
7 |
>> |
8 |
>>> On Thu, 2011-07-21 at 06:26 +0100, Mick wrote: |
9 |
> [...] |
10 |
>>> Ive just stumbled on something weird with march=native: |
11 |
>>> |
12 |
>>> At some point I had march=prescott on a core2 E4600 running 32bit - |
13 |
>>> worked well. Changed to march=native and did some upgrades with a few |
14 |
>>> odd things like asterisk segfaulting in a glibc library afterwards, and |
15 |
>>> some things not building. Then to add confusion, I changed to an |
16 |
>>> pentium Duo E6600 (flies!) and added another stick of ram. More odd |
17 |
>>> things happening such as reiserfs oopsing on shutdown. |
18 |
>>> |
19 |
>>> Last night the penny dropped and I looked the new processor up and |
20 |
>>> changed to march=core2 and have mostly corrected (recompiled) the |
21 |
>>> damage. |
22 |
>>> |
23 |
>>> So not sure about march=native now as it is only what was built with |
24 |
>>> native thats been problematic. With 20-20 hindsight it was perhaps |
25 |
>>> predictable ... |
26 |
>> |
27 |
>> IMO you're not supposed to compile part of the system with -march=<something> |
28 |
>> and the rest with -march=native. The instructions (and optimizations) |
29 |
>> emitted by -march=native might not be compatible with your previous |
30 |
>> -march. |
31 |
> |
32 |
> I'd like to see a reference for this claim. -march=native doesn't do |
33 |
> more than set -march=core2 and some other optimizations for cache size |
34 |
> etc. This should be no more troublesome than mixing code compiled with |
35 |
> different specific -march settings. When you look at binary |
36 |
> distributions (and especially precompiled packages from the developer |
37 |
> instead of the distribution), this is pretty much normal. |
38 |
> |
39 |
> The compiler is not allowed to change the external interfaces of |
40 |
> functions for optimization purposes (see [1]). Besides this, I can only |
41 |
> think of alignment problems ([2]) but even this should be handled |
42 |
> correctly by the compiler. Everything else is a compiler bug that should |
43 |
> be reported. |
44 |
> |
45 |
> [1] http://en.wikipedia.org/wiki/Calling_convention |
46 |
> [2] http://en.wikipedia.org/wiki/Data_alignment |
47 |
> |
48 |
> Regards, |
49 |
> Florian Philipp |
50 |
> |
51 |
|
52 |
I've just checked it by comparing the output of `gcc -v -Q -O2 |
53 |
-march=native test.c` with `gcc -v -Q -O2 -march=core2 test.c`: |
54 |
|
55 |
-march=native is resolved to: |
56 |
-march=core2 -mcx16 -msahf -mpopcnt -msse4.2 --param l1-cache-size=32 |
57 |
--param l1-cache-line-size=64 --param l2-cache-size=256 -mtune=core2 |
58 |
|
59 |
I also see that the -march=core2 version has the following options |
60 |
enabled: -mno-sse4 |
61 |
whereas -march=native enabled: -mpopcnt -msse4 -msse4.1 -msse4.2 |
62 |
|
63 |
-mssse3 and lower SSE versions were enabled in both cases. |
64 |
|
65 |
Regards, |
66 |
Florian Philipp |