# [Answered] "native" Cflag question

## MaximeG

Hi,

I was wondering whether the '-march=native' Cflag works well for an Intel Core i7 CPU ?

Regards,

Maxime

----------

## Veldrin

Without having hands on experience, consider the following. 

the -march=native flags looks at the cpu specs and then decide from a table what optimisations should be taken (or are considered useful form the developers point of view). It basically simplifies the selection process for the "best" -march=XXX option. 

IIRC gcc-4.3 has no profiles for corei7, thus the best optimisation you will get is (probably) core2.

and you can test it for yourself. (To be honest, I do not remember where the code comes from, but I guess from somewhere in this forum)

```
$ echo 'int main(){return 0;}' > test.c && gcc -v -Q -march=native -O2 test.c -o test && rm test.c test
```

I basically show what optimisations are used.

Below is a example run on my core2 machine.

 *Quote:*   

> nicolasc@ifirn ~ $ echo 'int main(){return 0;}' > test.c && gcc -v -Q -march=native -O2 test.c -o test && rm test.c test
> 
> Using built-in specs.                                                                                                   
> 
> Target: x86_64-pc-linux-gnu                                                                                             
> ...

 

cheers

V.

----------

## MaximeG

All right.

I'm currently using 'core2' with sse4, sse4.1, sse4.2.

I'll do the command for both core2 and native, trying to spot the differences  :Smile: 

Thanks,

Maxime

----------

## d2_racing

For my concern, I use -march=native, because if Gcc release a new Cflags that is valid for my CPU, then I will use it automagically.

----------

## Veldrin

fair enough

@MaximeG:

I completely forgot about the new instrucation sets in Corei7 - thus native could simplify the your config (resp CFLAGS line)

@d2_racing:

true - I sort of start to wonder why I stopped using it. (IIRC native can cause some ugly problems when used in cross-compiling over different archs [i.e core2 and athlon64])

Note to myself: switch to native.

cheers

V.

----------

## d2_racing

I think that GCC 4.4 will be optimised for CoreI7 or I wish that a release of it will include that CPU.

Right now, I think that -march=native will see a CoreI7 as a Core2 arch.

----------

## MaximeG

Yes, that's what I tought.

However I was wondering if native would behave as if it was Core2, or wouldn't behave at all  :Very Happy: 

Thanks,

Maxime

----------

## jmartos

I tried the above code with both "core2" and "native" on my system with dual Xeon E5530's and the only additional parameters that "native" added were the following.

```
--param l1-cache-size=32 --param l1-cache-line-size=64
```

----------

## d2_racing

And right now, I have no idea if core2 is faster then native or the opposite.

----------

## hielvc

If you use "native" or in my case k8-see3 and your running a 32bit system built with march=athlon-xp, does this change whats compiled to 64bits   :Question: 

----------

## Martux

 *hielvc wrote:*   

> If you use "native" or in my case k8-see3 and your running a 32bit system built with march=athlon-xp, does this change whats compiled to 64bits  

 

No.

That depends on what' s defined by the chost variable in /etc/make.conf:

CHOST="x86_64-pc-linux-gnu"

for a 64bit system.

----------

## hielvc

Thanks that what I thought, but I didnt want to spend the day rebuilding and then reboot into a nightmare   :Laughing: 

Still it set off one my pet pives. The last thing "emerge system" built was gcc. So if you want save time build gcc first, check gcc-config and select gcc-4.3.3 . now emerge -1 linux-headers glibc binutils. Now do a emerge -e world . Im being a good boy running portage 2.1.16. If you using portage-2.2 then then a --emptyree system and the world will work without recompileing a bunch of stuff. Or third choise would be emerge gcc and do you normal -uDN and after a couple of months most everything rebuilt with "native"

----------

