Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586

Dimitry Andric dim at
Thu Jul 21 13:51:34 UTC 2011

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.

More information about the freebsd-toolchain mailing list