This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Does -march=r5000 imply HAVE_64BIT_GPRS?
On Sat, Aug 18, 2001 at 03:01:13PM +0200, Thiemo Seufer wrote:
>
> This looks nice, but it isn't implemented for now. And it doesn't
> answer how the ELF header should look like in a case with both
> -mipsN an -march=XXX, what can in the end be destilled in this
> question:
>
> - Is EF_MIPS_MACH independent from EF_MIPS_ARCH or does it
> provide an override for EF_MIPS_ARCH for some cpu's?
>
> Current behaviour is "override".
>
> H.J.'s patch says also "override", but tells the assembler to fall
> back to the most restrictive header flags while generating code
> for the less restrictive settings.
>
> My patch does a step towards "independent" and may break things.
>
> Now, what's The Right Thing [TM] to do?
>
> In my now changed opinion, the "independent" case violates the
> K.I.S.S. principle without much gain. The "override" case OTOH
> should maintain consistency between header flags and the actual
> code, so -mipsN and -march=XXX should be _generally_ made
> incompatible. If there is need for something like the scenario
I think it is not a bad idea. We can do
if (mips_opts.isa != mips_isa_from_cpu)
{
/* -march=xxxx is not compatible with -mipsN. */
Issue a warning and abort.
}
In fact, I have changed my CFLAGS from "-march=r5000 -mips2" to
"-mtune=r5000 -mips2". The problem with this approach is only
gcc 3.1 and my current mips toolchain support -mtune=r5000. Maybe
we should just add a warning to my patch, saying please use
"-mtune=XXX -mipsN" instead of "-march=XXX -mipsN".
H.J.