[PATCH] GAS/MIPS: Add `-mfix-r5900' option for the R5900 short loop errata
Maciej W. Rozycki
macro@linux-mips.org
Fri Oct 26 20:12:00 GMT 2018
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
More information about the Binutils
mailing list