Re: mips64-linux-gnuabi64 testsuite breakage

[Richard Sandiford <richard.sandiford@arm.com>]

"Maciej W. Rozycki" <macro@orcam.me.uk> writes:
> On Wed, 26 Apr 2023, YunQiang Su wrote:
>
>> > Since 32f1c80375e "MIPS: support mips*64 as CPU and gnuabi64 as ABI",
>> 
>> I will fix the test suite.
>> The reason is that: the previous test suite assumes the default ABI is
>> n32 even the triple
>> with -gnuabi64.
>
>  I can see extra 3346 regressions across various MIPS targets compared to 
> a checkout from Jan.  Including ones like (parts of log trimmed for 
> clarity):
>
> ../as-new  --defsym count=960 /scratch/vol1/binutils/binutils-mips-test/binutils-src/gas/testsuite/gas/mips/branch-swap-2.s
> gas/testsuite/gas/mips/branch-swap-2.s:1: Fatal error: `micromips' cannot be used with `mips32r6'
> FAIL: MIPS branch swapping (960)
>
> for `mips-img-elf' which indicates that the default architecture has 
> changed for GAS for this target.  I think this is due to your commit 
> 9171de358f23 ("MIPS: default output r6 obj if the triple is r6"), which 
> has this part among others:
>
> +	# If Vendor is IMG, then MIPSr6 is used
> +	case ${target} in
> +	  mips*64*-img-*)
> +	    mips_cpu=mips64r6
> +	    ;;
> +	  mips*-img-*)
> +	    mips_cpu=mips32r6
> +	    ;;
> +	esac
>
> Not only this change is wrong (you can't just arbitrarily change a 
> configuration that has been in the wild for ~8.5 years as it'll break 
> things for people who rely on the established semantics),

It wasn't supposed to be an arbitrary change, but instead was supposed
to sync GAS's default to GCC's.  The GCC img toolchain has been an r6
toolchain since it was added in 2014.  The fact that GAS instead defaults
to mips1/mips3 seems like a bug, since mips1 isn't link-compatible with
mips32r6 and mips3 isn't link-compatible with mips64r6.

> but it hasn't been properly verified either, as a change is supposed
> not to cause regressions in the testsuite.

Can't argue with that part.  But...

>  Please revert the part quoted and fix the regressions.  Thank you.

...I think it does make sense to resurrect the patch in a testsuite-friendly
form.

Thanks,
Richard