This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] (Attempt to) Fix link compatibility check (was: Re:recent mips-elf linker "architecture ... incompatible" regressions)
> mips-foo-gcc -mips64 -Dnormal -o sffp_normal.o super-fast-fp-rtns.c
> mips-foo-gcc -mips64 -mips3d -Dmips3d -o sffp_mips3d.o super-fast-fp-rtns.c
>
> ?
>
Or how about this:
mips-foo-gcc -mips64 -mips3d foo.c
mips-foo-gcc -mips64 -mips3d bar.c
mips-foo-gcc foo.o bar.o -o a.exe
OK, so perhaps the ASEs aren't a good example at the moment, but if you
start having gcc vectorize or start using the 3d instructions when you
pass -mips3d then you start wanting it in the headers...
> Uh, so, what you're saying is, say you compile one module w/ -mips16
> and one without, and you link them together ... you get a warning?
>
> Isn't that _exactly_ how you're supposed to use mips16?
>
> compile your 10%-code-that-needs-high-performance with normal mips code,
> compile the 90%-reset code with -mips16, link them all together, and
> jalx (etc.) back and forth as needed?
>
> i'll admit freely that i've never actually used mips16... but from
> everything i've read that's how it's supposed to be used... 8-)
I've never seen it used this way. Most of the time I see it used where
they are going for code density all the way and just compile everything
with -mips16. For mips16 it's less of an issue (unless you start
misplacing object files and don't have mips16 support on the processor),
but I don't see the harm in warning about it either.
-eric
--
I will not use abbrev.