# -march for SU4100 (intel CULV processor)?

## Fran

Does anyone know the correct -march setting for an Intel SU4100 processor? I know about -march=native, but I'm not interested in that, since I use a different computer for compiling (an Intel Core 2 Quad Q6600 that builds the binary packages for itself and the SU4100 laptop).

My intention is to set the -march= to the least common denominator between the SU4100 and the Q6600. I assumed -march=native in the Q6600 would work, but I got an "illegal instruction" in the SU4100 when running gnome-sound-recorder and pressing the record button. All the other programs I've tested seem to work ok, but I prefer to play it safe and recompile everything with the new -march.

Thanks.

----------

## Telemin

You can find what options -march=native will invoke on each system by doing:

 *Quote:*   

> 
> 
> touch foo.c
> 
> gcc -march=native -### foo
> ...

 

And then look for the COLLECT_GCC_OPTIONS= line in the output.  That should make it easier to work out the common ground flags:)

-Telemin-

----------

## Fran

Thanks. This is weird, the only difference I see is "l2-cache-size=2048" and "l2-cache-size=4096", I wouldn't think that can cause an "illegal instruction" error:

```
$ diff output1 output2

7c7

<  "/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/cc1" "-quiet" "foo.c" "-D_FORTIFY_SOURCE=2" "-march=core2" "-mcx16" "-msahf" "--param" "l1-cache-size=32" "--param" "l1-cache-line-size=64" "--param" "l2-cache-size=2048" "-mtune=core2" "-quiet" "-dumpbase" "foo.c" "-auxbase" "foo" "-o" "/tmp/ccfukwds.s"

---

>  "/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/cc1" "-quiet" "foo.c" "-D_FORTIFY_SOURCE=2" "-march=core2" "-mcx16" "-msahf" "--param" "l1-cache-size=32" "--param" "l1-cache-line-size=64" "--param" "l2-cache-size=4096" "-mtune=core2" "-quiet" "-dumpbase" "foo.c" "-auxbase" "foo" "-o" "/tmp/cc7JdmFc.s"

9c9

<  "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/as" "-Qy" "-o" "/tmp/ccnpbNAK.o" "/tmp/ccfukwds.s"

---

>  "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/as" "-Qy" "-o" "/tmp/ccIAs0V9.o" "/tmp/cc7JdmFc.s"

13c13

<  "/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/collect2" "--eh-frame-hdr" "-m" "elf_x86_64" "-dynamic-linker" "/lib64/ld-linux-x86-64.so.2" "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64/crt1.o" "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64/crti.o" "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/crtbegin.o" "-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3" "-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3" "-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64" "-L/lib/../lib64" "-L/usr/lib/../lib64" "-L/opt/intel/Compiler/11.1/072/lib/intel64" "-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/lib" "-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../.." "/tmp/ccnpbNAK.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/crtend.o" "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64/crtn.o"

---

>  "/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/collect2" "--eh-frame-hdr" "-m" "elf_x86_64" "-dynamic-linker" "/lib64/ld-linux-x86-64.so.2" "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64/crt1.o" "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64/crti.o" "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/crtbegin.o" "-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3" "-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3" "-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64" "-L/lib/../lib64" "-L/usr/lib/../lib64" "-L/opt/intel/Compiler/11.1/072/lib/intel64" "-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/lib" "-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../.." "/tmp/ccIAs0V9.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/crtend.o" "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../lib64/crtn.o"
```

----------

## Telemin

I would imagine it certainly can.  If you imagine that a program tries to reference a memory address in the l2-cache space which doesn't exist, that would certainly cause a general protection fault, or whatever else it's called (I use the AMD and olde fashioned 8086 assembler terms).

What I don't know is what performance ramifications this would have for the Q6600 machine, and whether this would cause only half the cache to be used or if the effect is more subtle than this.

Also have you considered using distcc instead of (I assume) qpkg?  That way you can get the ideal flags for both machines, and still have the speed increase of the extra cores available on the desktop machine.

Sorry I can't give you concrete answers

-Telemin-

----------

