MIPS/libphobos: Fix switchcontext.S assembly for MIPS I ISA

Correct MIPS I assembly build errors in switchcontext.S:

.../libphobos/libdruntime/config/mips/switchcontext.S: Assembler messages:
.../libphobos/libdruntime/config/mips/switchcontext.S:50: Error: opcode not supported on this processor: mips1 (mips1) `sdc1 $f20,(0*8-((6*8+4+(-6*8+4&7))))($sp)'

etc., due to the use of the MIPS II LDC1 and SDC1 hardware instructions 
for FP register load and store operations.  Instead use the L.D and S.D 
generic assembly instructions, which are strict aliases for the LDC1 and 
SDC1 instructions respectively and produce identical machine code where 
the assembly for the MIPS II or a higher ISA has been requested, however 
they become assembly macros and expand to compatible sequences of LWC1 
and SWC1 hardware instructions where the assembly for the MIPS I ISA is 
in effect.

	libphobos/
	* libdruntime/config/mips/switchcontext.S [__mips_hard_float]: 
	Use L.D and S.D generic assembly instructions rather than LDC1 
	and SDC1 MIPS II hardware instructions.
---
Hi,

 Noticed in a build of a MIPS I toolchain.  I have no way to run MIPS 
regression-testing right now, however in `libopcodes' the L.D and S.D 
instructions are strict aliases valid for the MIPS II and higher ISAs, and 
just to double-check that I have built MIPS32r2 GCC with and without the 
change applied and verified with `objdump' that the respective target 
objects produced are identical.

 OK to apply to trunk, and -- as a fatal compilation error -- to backport 
to active release branches?

  Maciej
---
 libphobos/libdruntime/config/mips/switchcontext.S |   24 +++++++++++-----------
 1 file changed, 12 insertions(+), 12 deletions(-)

gcc-libphobos-mips1.diff

Excerpts from Maciej W. Rozycki's message of October 7, 2020 9:45 pm:
> Correct MIPS I assembly build errors in switchcontext.S:
> 
> .../libphobos/libdruntime/config/mips/switchcontext.S: Assembler messages:
> .../libphobos/libdruntime/config/mips/switchcontext.S:50: Error: opcode not supported on this processor: mips1 (mips1) `sdc1 $f20,(0*8-((6*8+4+(-6*8+4&7))))($sp)'
> 
> etc., due to the use of the MIPS II LDC1 and SDC1 hardware instructions 
> for FP register load and store operations.  Instead use the L.D and S.D 
> generic assembly instructions, which are strict aliases for the LDC1 and 
> SDC1 instructions respectively and produce identical machine code where 
> the assembly for the MIPS II or a higher ISA has been requested, however 
> they become assembly macros and expand to compatible sequences of LWC1 
> and SWC1 hardware instructions where the assembly for the MIPS I ISA is 
> in effect.
> 
> 	libphobos/
> 	* libdruntime/config/mips/switchcontext.S [__mips_hard_float]: 
> 	Use L.D and S.D generic assembly instructions rather than LDC1 
> 	and SDC1 MIPS II hardware instructions.
> ---
> Hi,
> 
>  Noticed in a build of a MIPS I toolchain.  I have no way to run MIPS 
> regression-testing right now, however in `libopcodes' the L.D and S.D 
> instructions are strict aliases valid for the MIPS II and higher ISAs, and 
> just to double-check that I have built MIPS32r2 GCC with and without the 
> change applied and verified with `objdump' that the respective target 
> objects produced are identical.
> 
>  OK to apply to trunk, and -- as a fatal compilation error -- to backport 
> to active release branches?
> 

Fine with me, thanks.

Iain.

On Thu, 8 Oct 2020, Iain Buclaw wrote:

> >  Noticed in a build of a MIPS I toolchain.  I have no way to run MIPS 
> > regression-testing right now, however in `libopcodes' the L.D and S.D 
> > instructions are strict aliases valid for the MIPS II and higher ISAs, and 
> > just to double-check that I have built MIPS32r2 GCC with and without the 
> > change applied and verified with `objdump' that the respective target 
> > objects produced are identical.
> > 
> >  OK to apply to trunk, and -- as a fatal compilation error -- to backport 
> > to active release branches?
> > 
> 
> Fine with me, thanks.

 Applied to trunk, thanks.

 Jakub, Richard: I should have cc-ed you for the backports to GCC 8/9/10.  
OK to backport as a fatal build failure fix, or shall we leave this as it 
stands?  FAOD the L.D and S.D assembly instructions have been supported in 
binutils as long as the MIPS port has, i.e. from:

commit 45b1470513cfef2af6fd5532d33a54a840b4600a
Author: Ian Lance Taylor <ian@airs.com>
Date:   Wed Aug 18 19:40:37 1993 +0000

  Maciej

On Mon, 12 Oct 2020, Maciej W. Rozycki wrote:

> On Thu, 8 Oct 2020, Iain Buclaw wrote:
> 
> > >  Noticed in a build of a MIPS I toolchain.  I have no way to run MIPS 
> > > regression-testing right now, however in `libopcodes' the L.D and S.D 
> > > instructions are strict aliases valid for the MIPS II and higher ISAs, and 
> > > just to double-check that I have built MIPS32r2 GCC with and without the 
> > > change applied and verified with `objdump' that the respective target 
> > > objects produced are identical.
> > > 
> > >  OK to apply to trunk, and -- as a fatal compilation error -- to backport 
> > > to active release branches?
> > > 
> > 
> > Fine with me, thanks.
> 
>  Applied to trunk, thanks.
> 
>  Jakub, Richard: I should have cc-ed you for the backports to GCC 8/9/10.  
> OK to backport as a fatal build failure fix, or shall we leave this as it 
> stands?  FAOD the L.D and S.D assembly instructions have been supported in 
> binutils as long as the MIPS port has, i.e. from:
> 
> commit 45b1470513cfef2af6fd5532d33a54a840b4600a
> Author: Ian Lance Taylor <ian@airs.com>
> Date:   Wed Aug 18 19:40:37 1993 +0000

Sure.

Richard.

On Tue, 13 Oct 2020, Richard Biener wrote:

> >  Jakub, Richard: I should have cc-ed you for the backports to GCC 8/9/10.  
> > OK to backport as a fatal build failure fix, or shall we leave this as it 
> > stands?  FAOD the L.D and S.D assembly instructions have been supported in 
> > binutils as long as the MIPS port has, i.e. from:
> > 
> > commit 45b1470513cfef2af6fd5532d33a54a840b4600a
> > Author: Ian Lance Taylor <ian@airs.com>
> > Date:   Wed Aug 18 19:40:37 1993 +0000
> 
> Sure.

 Thanks, backported to GCC 10 & 9.  There has been no libphobos or the D 
frontend in GCC 8, so no backport needed there.

  Maciej