Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

["H . J . Lu" <hjl at lucon dot org>]

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.