[PATCH] GAS/MIPS: Add `-mfix-r5900' option for the R5900 short loop errata

[Maciej W. Rozycki]

On Fri, 26 Oct 2018, Fredrik Noring wrote:

> Then -march=r5900 implies -mfix-r5900, which means a target such as
> mipsr5900-unknown-linux-gnu automatically has -mfix-r5900 even when
> generating code with -mips3 (without explicitly given -mfix-r5900).
> I thought that would provide the best guarantees of generating R5900
> compatible code, under the broadest circumstances. However, none of
> the other -mfix-* options seem to operate like that, so I scratched
> that idea. Besides, it also failed to handle -mno-fix-r5900.

 None of the other `-mfix-*' settings is implied by any of the `-march=' 
options though.

> Given that the variable mips_fix_r5900 is TRUE or FALSE, should I use
> another variable or mechanism to check whether the option is actually
> given as opposed to being implied? How to tell the difference?

 Have a look at GCC, they have `target_flags_explicit' to tell defaulted 
from explicit cases, and use that for their `-mfix-*' options.  You can 
use that as a template and adapt for our purposes here.  You'll want to 
have `-mfix-r5900' eventually implemented for GCC too, I suppose.

> >  Did you run regression-testing with your change?  How did you verify it?
> 
> Yes, I checked it with "make RUNTESTFLAGS=mips.exp check-gas", including
> provisionally discarding -mfix-r5900 from the file r5900-fix.d to verify
> that a test failure was triggered.

 What target was that with though?

> As usual, six unrelated tests fail in the R5900 target test suite:
> 
> FAIL: MIPS CP0 register disassembly (numeric)
> FAIL: MIPS CP0 register disassembly (mips32)
> FAIL: MIPS CP0 register disassembly (mips32r2)
> FAIL: MIPS CP0 register disassembly (mips64)
> FAIL: MIPS CP0 register disassembly (mips64r2)
> FAIL: MIPS CP0 register disassembly (sb1)

 But are these actual regressions or preexisting failures?

> By the way, I'm still waiting for the paperwork from the FSF.

 How come Nick has committed your previous change then?  From that I 
inferred the paperwork was sorted already (Nick as the head maintainer has 
access to FSF copyright assignment records; I don't).

  Maciej