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