On Mon, 21 Nov 2011 23:19:08 +0100 Olivier Smedts <oliv...@gid0.org> wrote:
> 2011/11/21 Conrad J. Sabatier <conr...@cox.net>: > > > > I've been using the (undocumented, at least in /etc/make.conf) > > CPUTYPE?=native with no problems for quite some time now. Let gcc > > detect the processor type and generate the appropriate code. > > Eliminates any guesswork in trying to select the correct setting for > > CPUTYPE. > > CPUTYPE=native is not recognized by /usr/share/mk/bsd.cpu.mk (that's > the real purpose of CPUTYPE, it does not only change the -march > compiler setting). > The proper way of doing what you're doing, after numerous tests and > researchs, seems to be : > > CPUTYPE?=core2 (for example, to let /usr/share/mk/bsd.cpu.mk do its > job) CFLAGS=-O2 -pipe -march=native (because you want the compiler to > detect the cpu it's running on and optimize the code for it) > NO_CPU_CFLAGS=yes (because you wanted to force the -march, you don't > want another one to be added on the command line) > COPTFLAGS=-O2 -pipe -march=native (same thing for kernel CFLAGS) > NO_CPU_COPTFLAGS=yes > > This way, bsd.cpu.mk can set useful MACHINE_CPU for your CPUTYPE, but > you let the compiler determine which processor to optimize the code > for with the -march. I add NO_CPU_CFLAGS and NO_CPU_COPTFLAGS to be > able to specify -march=native in the CFLAGS, cause it's different from > CPUTYPE. > > Now why do I force -march=core2 and don't use -march=native ? Because > our base gcc does not use the correct flags on my Core2 CPU if using > -march=native : > % /usr/bin/gcc -### -march=native md5.c > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.1 20070831 patched [FreeBSD] > "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "md5.c" "-march=core2" > "-mtune=generic" "-quiet" "-dumpbase" "md5.c" "-auxbase" "md5" "-o" > "/var/tmp//ccYJKvGN.s" > "/usr/bin/as" "-Qy" "-o" "/var/tmp//ccR6Lu5X.o" > "/var/tmp//ccYJKvGN.s" "/usr/bin/ld" "--eh-frame-hdr" > "-dynamic-linker" "/libexec/ld-elf.so.1" "/usr/lib/crt1.o" > "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "-L/usr/lib" > "/var/tmp//ccR6Lu5X.o" "-lgcc" "--as-needed" "-lgcc_s" > "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" > "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" > > See the "-mtune=generic" ? Crap ! You don't want that (manpage : > Produce code optimized for the most common IA32/AMD64/EM64T > processors. If you know the CPU on which your code will run, then you > should use the corresponding -mtune option instead of -mtune=generic. > But, if you do not know exactly what CPU users of your application > will have, then you should use this option.) > > % /usr/bin/gcc -### -march=core2 md5.c > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.1 20070831 patched [FreeBSD] > "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "md5.c" "-quiet" > "-dumpbase" "md5.c" "-march=core2" "-auxbase" "md5" "-o" > "/var/tmp//ccL8Bvk4.s" > "/usr/bin/as" "-Qy" "-o" "/var/tmp//ccLrppPo.o" > "/var/tmp//ccL8Bvk4.s" "/usr/bin/ld" "--eh-frame-hdr" > "-dynamic-linker" "/libexec/ld-elf.so.1" "/usr/lib/crt1.o" > "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "-L/usr/lib" > "/var/tmp//ccLrppPo.o" "-lgcc" "--as-needed" "-lgcc_s" > "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" > "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" > > No -mtune=generic. According to the gcc manpage for the x86 arch, > -march=core2 is sufficient to have proper values for -mtune, -mcpu... > (Generate instructions for the machine type cpu-type. The choices for > cpu-type are the same as for -mtune. Moreover, specifying > -march=cpu-type implies -mtune=cpu-type.) Strange, it seems to "just work" on my machine (note the -march and -mtune settings): $ /usr/bin/gcc -### -march=native hello.c Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "hello.c" "-march=k8" "-mtune=k8" "-quiet" "-dumpbase" "hello.c" "-auxbase" "hello" "-o" "/tmp/ccAXYamu.s" "/usr/bin/as" "-Qy" "-o" "/tmp/ccIpMJgw.o" "/tmp/ccAXYamu.s" "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "-L/usr/lib" "/tmp/ccIpMJgw.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" I've never seen any problems with this in src or ports makes, either. I do seem to recall having a look at bsd.cpu.mk a long, long time ago, and it appeared to me that it simply passed any unrecognized CPUTYPE through unchanged, which my experience does seem to bear out. -- Conrad J. Sabatier conr...@cox.net _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"