This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] (Attempt to) Fix link compatibility check (was: Re: recent mips-elf linker "architecture ... incompatible" regressions)


Eric Christopher wrote:
> 
> > 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...

AFAICS ASE's are designed to be used together with a base architecture,
so there is not much point in warning about ASE flags as long as the
ASE isn't incompatible to the base arch (Is there any of this sort?).
IMHO it's best to keep the union of all ASE flags in the final
executable.

Checking CPU type is a different thing because of subtle
incompatibilities. AFAICS we should either (try to) warn about any
incompatibility or we shouldn't make any attempt on it.


Thiemo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]