On 2011-07-21 14:17, Julian H. Stacey wrote:
Summary: I found a problem with CFLAGS += -march=i586 on an i686 linking a crt.o for an i686, then not running on an i586,
IMHO this is a bit of a PEBKAC issue. If you change CPUFLAGS to target a specific CPU, you should really rebuild all of world with it, not just a single program. In fact, you should rebuild all your ports too.
I suggested maybe -march could be extended to also select seperate lib sub directories to at least trigger a link failure, rather than a silent apparent good compile of a bad binary.
I think this would add a whole lot of complexity for very little gain, and still not save you from potential problems. You would really have to use the same approach for all system libraries, otherwise you might link in something from e.g. libc or libcrypto that was optimized for the wrong CPU. And I'm not even mentioning objects and/or libraries from ports... :) The compiler cannot automagically determine whether any object or library file you link into your program is fit to run on the CPU you are targeting, unless you would add information specifying the CPU type (and other particulars) to the object files themselves. In the end, it is up to you to make sure you do not mix "incompatible" object code. Having said all this, if you are worried particularly about the crt*.o files, then we could simply always build those with 'lowest common denominator' flags, like we do with e.g. the dynamic linker. I doubt very much that the startup code gains any performance by optimizing for higher CPU types. _______________________________________________ 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"
