Re: RFC & patch: Rework MIPS command-line handling

[Richard Sandiford <rsandifo at redhat dot com>]

"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes:
> > (2) Traditionally, GCC has tried to infer sensible things from a sparse
> >     command line.  Passing -mipsN would select a suitable ABI for ISA N,
> >     passing -mabi=FOO would select a suitable ISA for ABI FOO, and so on.
> >     Lately, gas has done the same thing, although the assumptions are
> >     slightly different (more later).
> > 
> >     If -march is going to act like -mipsN, then it ought to choose the
> >     ABI as well.  For example, if "mips64-elf-gcc -mips1" chooses o32 code
> >     (as it does now) then "mips64-elf-gcc -march=r3000" should do the same.
> 
>  I'd prefer to select the default ABI at the configure time, from the
> target triplet ideally.  E.g. I use a local patch that select the 64 ABI
> as the default for binutils if configuring for mips64*-*-linux*.  The same
> is set in the specs file for gcc for this target.

Well, the GAS patch was written so that NO_ABI would be the default for
most configs, but that you could override it for particular target
triples where appropriate.  mips64-linux-gnu is probably a prime
candidate for that.

It might also be nice to have a --with-abi configure option,
although that's something we could add later...

> >     (b) Passing -mips3 to an n32 MIPS III config (e.g. mips-sgi-irix6)
> > 	will select n64, which seems counter-intuitive.
> 
>  Agreed, I think nothing beside the "-mabi=" and the "-32", "-n32" and
> "-64" options should change the default ABI. 

[And in a later message]

>  How can you guess an ABI from anything else?  If I pass the "-march=4000"
> option, then which ABI do I mean?  If I pass "-mips4" for conditional
> moves, then why should I add "-32" to keep the ABI unchanged?

The reason for -mgp32 is for consitency with EABIs.  If you
have a 32-bit EABI configuration like mipstx39-elf, does
-mips4 select 64-bit EABI code, or 32-bit EABI code?  The
first seems most natural to me, so the rule was: if you
select a 64-bit processor, you get 64-bit code, unless
you also select -mgp32.

In general, the main reason to keep the implicit ABI selection
is that that's what we've done before.  I didn't think there'd
be much support for dropping it entirely.

On the other hand, my main complaint with the current code is
that it changes the ABI even when you wouldn't expect it to.
If others agree that there should be no implicit ABI selection,
I'm happy to submit a revised version.

The main difficulty with dropping the ABI selection entirely
is: how do you select between the 32-bit and 64-bit versions
of the EABIs?  mipstx39-elf-gcc generates 32-bit EABI code
by default.  What happens if you select a 64-bit processor?
Options I can see:

1. Stick with the idea in the patch I sent.  Selecting a 64-bit
   processor would usually select the 64-bit EABI, but adding
   -mgp32 forces the 32-bit version.

2. Reverse of (1).  You get the 32-bit version of the EABI
   unless you use -mgp64.

3. Add eabi32, eabi64, meabi32 and meabi64 to -mabi.  You get
   the 32-bit version unless you use -mabi=eabi64.

Richard