On Tue Nov 8 11, Dimitry Andric wrote: > On 2011-11-08 01:25, Alexander Best wrote: > > i've seen dozens of issues, where people set CPUTYPE=native. although this > > works in a lot of cases, it doesn't in others. why don't we simply add > > something like > > > > . if ${CPUTYPE} == "native" > > . error "bla" > > . endif > > > > in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is > > known to cause problems. > > What does this solve? Don't you think it is better to try to fix the > actual problems? Some people like being able to optimize for their > specific CPU, however much you can shoot yourself in the foot with it.
just wanted to report that i found an issue with CPUTYPE "native". simply do the following on amd64 (i tested this on ref9-amd64.freebsd.org): make.conf: CPUTYPE ?= native CFLAGS = -O2 -pipe -fno-strict-aliasing -funroll-loops -fno-builtin KERNCONF = GENERIC now 'make buildworld' and enjoy the signal 11. ;) setting CPUTYPE to nocona or commenting it out lets 'mak buildworld' succeed. cheers. alex there's a problem report for this already: http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/149712 > > I haven't seen any consistent bug reports yet, just a lot of complaints > that indicate a rather high probability of PEBKAC. > > And just to counter the nay-saying, I compiled a number of boxes with > clang -march=native (mostly of the Xeon/i7 variant) and I haven't seen > any problems at all. _______________________________________________ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"