Re: [MIPS r5900] libgcc floating point fixes

Re: [MIPS r5900] libgcc floating point fixes

[Woon yung Liu]

Hi,

I refer to the previous message by Juergen, regarding his patch to libgcc.
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01725.html

As of now, libgcc (of GCC v5.3.0) still has the problem of building support for both soft and hard floats, when there is no support for hard floats by the R5900 (and hence resulting in the generation of recursive functions like extendsfdf2).

That patch doesn't seem to have been committed. I would very much like to help to see it get committed because GCC's support for the R5900 is currently not suitable for PlayStation 2 development; software-floating point emulation is severely detrimental to performance.
What else needs to be done first, before it can be accepted?

Thanks and regards,
-W Y

Re: [MIPS r5900] libgcc floating point fixes

[Woon yung Liu]

Hi,

Bump! Sorry, but could I please get an answer? I'm willing to update the patch without credit, if necessary.
The patch is working for the R5900 hard-fp mode. I've also used the same, patched copy of GCC, to build the toolchain for the IOP (MIPS R3000A, 32-bit MIPS I with no FPU) and it also builds correctly.

If I should be writing to someone else specifically, could someone please tell me who I should be writing to instead?


Thanks and regards,
-W Y



On Tuesday, January 26, 2016 5:41 PM, Woon yung Liu <ysai187@yahoo.com> wrote:
Hi,

I refer to the previous message by Juergen, regarding his patch to libgcc.
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01725.html

As of now, libgcc (of GCC v5.3.0) still has the problem of building support for both soft and hard floats, when there is no support for hard floats by the R5900 (and hence resulting in the generation of recursive functions like extendsfdf2).

That patch doesn't seem to have been committed. I would very much like to help to see it get committed because GCC's support for the R5900 is currently not suitable for PlayStation 2 development; software-floating point emulation is severely detrimental to performance.
What else needs to be done first, before it can be accepted?

Thanks and regards,
-W Y

RE: [MIPS r5900] libgcc floating point fixes

[Matthew Fortune]

Woon yung Liu <ysai187@yahoo.com> wries
> Bump! Sorry, but could I please get an answer? I'm willing to update the patch without
> credit, if necessary.

Hi WY,

Apologies for exceptionally slow response.

The patch you referenced is mostly OK but I would like to get the MIPS16 check
changed to a configure time check for MIPS16 support rather than checking for
r5900. I.e. I think we should have GCC raise an error for -march=r5900 -mips16
and then a configure time check using just -mips16 would fail. That can then
be used to choose whether to build the mips16 code instead of this:

+	if test x$with_arch != xr5900; then
+		tmake_file="$tmake_file mips/t-mips16"
+	fi

This change should also make it possible to have mips.exp simply skip the mips16
tests for r5900 without having to tell it explicitly about r5900.

Thanks,
Matthew

> The patch is working for the R5900 hard-fp mode. I've also used the same, patched copy of
> GCC, to build the toolchain for the IOP (MIPS R3000A, 32-bit MIPS I with no FPU) and it
> also builds correctly.
> 
> If I should be writing to someone else specifically, could someone please tell me who I
> should be writing to instead?
> 
> 
> Thanks and regards,
> -W Y
> 
> 
> 
> On Tuesday, January 26, 2016 5:41 PM, Woon yung Liu <ysai187@yahoo.com> wrote:
> Hi,
> 
> I refer to the previous message by Juergen, regarding his patch to libgcc.
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01725.html
> 
> As of now, libgcc (of GCC v5.3.0) still has the problem of building support for both soft
> and hard floats, when there is no support for hard floats by the R5900 (and hence
> resulting in the generation of recursive functions like extendsfdf2).
> 
> That patch doesn't seem to have been committed. I would very much like to help to see it
> get committed because GCC's support for the R5900 is currently not suitable for
> PlayStation 2 development; software-floating point emulation is severely detrimental to
> performance.
> What else needs to be done first, before it can be accepted?
> 
> Thanks and regards,
> -W Y

Re: [MIPS r5900] libgcc floating point fixes

[Woon yung Liu]

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

Hi Matt,

Thank you for your feedback.

New changes in this updated version:

gcc/config/mips/mips.c:added a check against the use of both -mips16 and -march=r5900.
libgcc/configure.ac:added a check for the support of -mips16 by the target.
libgcc/config.host: replaced all explicit checks for the r5900 arch with a test for libgcc_cv_mips16, when checking for whether the MIPS16 ASE is supported.



I have tested the mechanism by replacing the test for -mips16 with -mno-mips16, and I can see the test result for libgcc_cv_mips16 within config.host getting changed.


Please feel free to give further comments.

Thanks and regards,
-W Y


On Tuesday, February 23, 2016 5:09 PM, Matthew Fortune <Matthew.Fortune@imgtec.com> wrote:
Woon yung Liu <ysai187@yahoo.com> wries
> Bump! Sorry, but could I please get an answer? I'm willing to update the patch without
> credit, if necessary.

Hi WY,

Apologies for exceptionally slow response.

The patch you referenced is mostly OK but I would like to get the MIPS16 check
changed to a configure time check for MIPS16 support rather than checking for
r5900. I.e. I think we should have GCC raise an error for -march=r5900 -mips16
and then a configure time check using just -mips16 would fail. That can then
be used to choose whether to build the mips16 code instead of this:

+    if test x$with_arch != xr5900; then
+        tmake_file="$tmake_file mips/t-mips16"
+    fi

This change should also make it possible to have mips.exp simply skip the mips16
tests for r5900 without having to tell it explicitly about r5900.

Thanks,
Matthew


> The patch is working for the R5900 hard-fp mode. I've also used the same, patched copy of
> GCC, to build the toolchain for the IOP (MIPS R3000A, 32-bit MIPS I with no FPU) and it
> also builds correctly.
> 
> If I should be writing to someone else specifically, could someone please tell me who I
> should be writing to instead?
> 
> 
> Thanks and regards,
> -W Y
> 
> 
> 
> On Tuesday, January 26, 2016 5:41 PM, Woon yung Liu <ysai187@yahoo.com> wrote:
> Hi,
> 
> I refer to the previous message by Juergen, regarding his patch to libgcc.
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01725.html
> 
> As of now, libgcc (of GCC v5.3.0) still has the problem of building support for both soft
> and hard floats, when there is no support for hard floats by the R5900 (and hence
> resulting in the generation of recursive functions like extendsfdf2).
> 
> That patch doesn't seem to have been committed. I would very much like to help to see it
> get committed because GCC's support for the R5900 is currently not suitable for
> PlayStation 2 development; software-floating point emulation is severely detrimental to
> performance.
> What else needs to be done first, before it can be accepted?
> 
> Thanks and regards,
> -W Y

[-- Attachment #2: gcc-5.3.0-libgcc-160224.patch --]
[-- Type: application/octet-stream, Size: 7854 bytes --]

diff -rupNb orig/gcc-5.3.0/gcc/config/mips/mips.c gcc-5.3.0/gcc/config/mips/mips.c
--- orig/gcc-5.3.0/gcc/config/mips/mips.c	2015-08-05 19:20:59.000000000 +0800
+++ gcc-5.3.0/gcc/config/mips/mips.c	2016-02-24 23:22:47.100313900 +0800
@@ -17438,6 +17438,11 @@ mips_option_override (void)
     error ("unsupported combination: %s",
 	   "-march=r5900 -mhard-float -mdouble-float");
 
+  /* The R5900 does not support some MIPS16 instructions.  */
+  if (TARGET_MIPS5900 && ((mips_base_compression_flags & MASK_MIPS16) != 0))
+	  error("unsupported combination: %s",
+		  "-march=r5900 -mips16");
+
   /* If a -mlong* option was given, check that it matches the ABI,
      otherwise infer the -mlong* setting from the other options.  */
   if ((target_flags_explicit & MASK_LONG64) != 0)
diff -rupNb orig/gcc-5.3.0/libgcc/config/t-hardfp-sf gcc-5.3.0/libgcc/config/t-hardfp-sf
--- orig/gcc-5.3.0/libgcc/config/t-hardfp-sf	1970-01-01 07:30:00.000000000 +0730
+++ gcc-5.3.0/libgcc/config/t-hardfp-sf	2016-02-24 16:25:02.323338000 +0800
@@ -0,0 +1,32 @@
+# Copyright (C) 2014-2015 Free Software Foundation, Inc.
+
+# This file is part of GCC.
+
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# <http://www.gnu.org/licenses/>.
+
+hardfp_float_modes := sf
+# di and ti are provided by libgcc2.c where needed.
+hardfp_int_modes := si
+hardfp_extensions :=
+hardfp_truncations :=
+
+# Emulate 64 bit float:
+FPBIT = true
+DPBIT = true
+# Don't build functions handled by 32 bit hardware:
+LIB2FUNCS_EXCLUDE = _addsub_sf _mul_sf _div_sf \
+    _fpcmp_parts_sf _compare_sf _eq_sf _ne_sf _gt_sf _ge_sf \
+    _lt_sf _le_sf _unord_sf _si_to_sf _sf_to_si _negate_sf \
+    _thenan_sf _sf_to_usi _usi_to_sf
diff -rupNb orig/gcc-5.3.0/libgcc/config.host gcc-5.3.0/libgcc/config.host
--- orig/gcc-5.3.0/libgcc/config.host	2015-10-01 20:01:18.000000000 +0800
+++ gcc-5.3.0/libgcc/config.host	2016-02-24 18:34:58.842941900 +0800
@@ -144,7 +144,11 @@ mips*-*-*)
 	cpu_type=mips
 	tmake_file="mips/t-mips"
 	if test "${libgcc_cv_mips_hard_float}" = yes; then
+	    if test "${libgcc_cv_mips_single_float}" = yes; then
+                tmake_file="${tmake_file} t-hardfp-sf t-hardfp"
+	    else
 		tmake_file="${tmake_file} t-hardfp-sfdf t-hardfp"
+	    fi
 	else
 		tmake_file="${tmake_file} t-softfp-sfdf"
 	fi
@@ -832,19 +836,16 @@ mips*-*-netbsd*)			# NetBSD/mips, either
 mips*-*-linux*)				# Linux MIPS, either endian.
 	extra_parts="$extra_parts crtfastmath.o"
 	tmake_file="${tmake_file} t-crtfm"
-	case ${host} in
-	  mips64r5900* | mipsr5900*)
-	    # The MIPS16 support code uses floating point
-	    # instructions that are not supported on r5900.
-	    ;;
-	  *)
+    if test "${libgcc_cv_mips16}" = yes; then
 	    tmake_file="${tmake_file} mips/t-mips16 t-slibgcc-libgcc"
-	    ;;
-	esac
+    fi
 	md_unwind_header=mips/linux-unwind.h
 	;;
 mips*-sde-elf*)
-	tmake_file="$tmake_file mips/t-crtstuff mips/t-mips16"
+	tmake_file="$tmake_file mips/t-crtstuff"
+    if test "${libgcc_cv_mips16}" = yes; then
+	  tmake_file="${tmake_file} mips/t-mips16"
+    fi
 	case "${with_newlib}" in
 	  yes)
 	    # newlib / libgloss.
@@ -874,7 +875,10 @@ mipsisa64sb1-*-elf* | mipsisa64sb1el-*-e
 	extra_parts="$extra_parts crti.o crtn.o"
 	;;
 mips-*-elf* | mipsel-*-elf*)
-	tmake_file="$tmake_file mips/t-elf mips/t-crtstuff mips/t-mips16"
+	tmake_file="$tmake_file mips/t-elf mips/t-crtstuff"
+    if test "${libgcc_cv_mips16}" = yes; then
+	  tmake_file="${tmake_file} mips/t-mips16"
+    fi
 	extra_parts="$extra_parts crti.o crtn.o"
 	;;
 mipsr5900-*-elf* | mipsr5900el-*-elf*)
@@ -882,7 +886,10 @@ mipsr5900-*-elf* | mipsr5900el-*-elf*)
 	extra_parts="$extra_parts crti.o crtn.o"
 	;;
 mips64-*-elf* | mips64el-*-elf*)
-	tmake_file="$tmake_file mips/t-elf mips/t-crtstuff mips/t-mips16"
+	tmake_file="$tmake_file mips/t-elf mips/t-crtstuff"
+    if test "${libgcc_cv_mips16}" = yes; then
+	  tmake_file="${tmake_file} mips/t-mips16"
+    fi
 	extra_parts="$extra_parts crti.o crtn.o"
 	;;
 mips64r5900-*-elf* | mips64r5900el-*-elf*)
@@ -898,7 +905,10 @@ mips64orion-*-elf* | mips64orionel-*-elf
 	extra_parts="$extra_parts crti.o crtn.o"
 	;;
 mips*-*-rtems*)
-	tmake_file="$tmake_file mips/t-elf mips/t-crtstuff mips/t-mips16"
+	tmake_file="$tmake_file mips/t-elf mips/t-crtstuff"
+    if test "${libgcc_cv_mips16}" = yes; then
+	  tmake_file="${tmake_file} mips/t-mips16"
+    fi
 	extra_parts="$extra_parts crti.o crtn.o"
 	;;
 mips-wrs-vxworks)
diff -rupNb orig/gcc-5.3.0/libgcc/configure gcc-5.3.0/libgcc/configure
--- orig/gcc-5.3.0/libgcc/configure	2015-10-01 19:51:45.000000000 +0800
+++ gcc-5.3.0/libgcc/configure	2016-02-24 23:15:09.480329700 +0800
@@ -4702,6 +4702,48 @@ rm -f core conftest.err conftest.$ac_obj
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $libgcc_cv_mips_hard_float" >&5
 $as_echo "$libgcc_cv_mips_hard_float" >&6; }
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the target is single-float" >&5
+$as_echo_n "checking whether the target is single-float... " >&6; }
+if test "${libgcc_cv_mips_single_float+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+#ifndef __mips_single_float
+     #error FOO
+     #endif
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  libgcc_cv_mips_single_float=yes
+else
+  libgcc_cv_mips_single_float=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libgcc_cv_mips_single_float" >&5
+$as_echo "$libgcc_cv_mips_single_float" >&6; }
+  # Some targets (i.e. R5900) don't support some MIPS16 instructions.
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the target supports the MIPS16 ASE" >&5
+$as_echo_n "checking whether the target supports MIPS16 ASE... " >&6; }
+if test "${libgcc_cv_mips16+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+  CFLAGS_hold=$CFLAGS
+		 CFLAGS="$CFLAGS -mips16"
+		 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+int i;
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  libgcc_cv_mips16=yes
+else
+  libgcc_cv_mips16=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+	CFLAGS=$CFLAGS_hold
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libgcc_cv_mips16" >&5
+$as_echo "$libgcc_cv_mips16" >&6; }
 esac
 
 case ${host} in
diff -rupNb orig/gcc-5.3.0/libgcc/configure.ac gcc-5.3.0/libgcc/configure.ac
--- orig/gcc-5.3.0/libgcc/configure.ac	2015-10-01 19:51:45.000000000 +0800
+++ gcc-5.3.0/libgcc/configure.ac	2016-02-24 23:15:03.724861800 +0800
@@ -340,6 +340,23 @@ mips*-*-*)
      #endif],
     [libgcc_cv_mips_hard_float=yes],
     [libgcc_cv_mips_hard_float=no])])
+  AC_CACHE_CHECK([whether the target is single-float],
+		 [libgcc_cv_mips_single_float],
+		 [AC_COMPILE_IFELSE(
+    [#ifndef __mips_single_float
+     #error FOO
+     #endif],
+    [libgcc_cv_mips_single_float=yes],
+    [libgcc_cv_mips_single_float=no])])
+  # Some targets (i.e. R5900) don't support some MIPS16 instructions.
+  AC_CACHE_CHECK([whether the target supports the MIPS16 ASE],
+		 [libgcc_cv_mips16],
+		 [CFLAGS_hold=$CFLAGS
+		 CFLAGS="$CFLAGS -mips16"
+		 AC_COMPILE_IFELSE([[int i;]],
+    [libgcc_cv_mips16=yes],
+    [libgcc_cv_mips16=no])
+	CFLAGS=$CFLAGS_hold])
 esac
 
 case ${host} in

Re: [MIPS r5900] libgcc floating point fixes

[Woon yung Liu]

Hi again,

Could I please have a status update?

Thanks and Regards,
-W Y

Re: [MIPS r5900] libgcc floating point fixes

[Woon yung Liu]

Hi again,

Could I please have a status update?

Thanks and Regards,
-W Y

RE: [MIPS r5900] libgcc floating point fixes

[Matthew Fortune]

Hi Woon Yung,

Woon yung Liu <ysai187@yahoo.com> writes:
> Thank you for your feedback.
> 
> New changes in this updated version:
> 
> gcc/config/mips/mips.c:added a check against the use of both -mips16 and
> -march=r5900.
> libgcc/configure.ac:added a check for the support of -mips16 by the
> target.
> libgcc/config.host: replaced all explicit checks for the r5900 arch with
> a test for libgcc_cv_mips16, when checking for whether the MIPS16 ASE is
> supported.
> 
> 
> 
> I have tested the mechanism by replacing the test for -mips16 with -mno-
> mips16, and I can see the test result for libgcc_cv_mips16 within
> config.host getting changed.
> 
> 
> Please feel free to give further comments.

Sorry for the delay, I was waiting for trunk to open and then go side tracked.
With a tweak to the new check in mips.c I think this is looking OK.

Do you have GCC FSF copyright assignment in place? Your change might be small
enough not to need it but it assignment would make it easier.

I can find copyright assignment from Joergen who was original author of this
which is good news.

I assume you are planning on submitting your work on r5900 vector support which
will certainly need copyright assignment so this could be a good time to sort
it out. Sorry for not checking this earlier so this could already be in
progress.

Let me know and I'll send the forms.

Thanks,
Matthew

> 
> Thanks and regards,
> -W Y
> 
> 
> On Tuesday, February 23, 2016 5:09 PM, Matthew Fortune
> <Matthew.Fortune@imgtec.com> wrote:
> Woon yung Liu <ysai187@yahoo.com> wries
> > Bump! Sorry, but could I please get an answer? I'm willing to update
> > the patch without credit, if necessary.
> 
> Hi WY,
> 
> Apologies for exceptionally slow response.
> 
> The patch you referenced is mostly OK but I would like to get the MIPS16
> check changed to a configure time check for MIPS16 support rather than
> checking for r5900. I.e. I think we should have GCC raise an error for -
> march=r5900 -mips16 and then a configure time check using just -mips16
> would fail. That can then be used to choose whether to build the mips16
> code instead of this:
> 
> +    if test x$with_arch != xr5900; then
> +        tmake_file="$tmake_file mips/t-mips16"
> +    fi
> 
> This change should also make it possible to have mips.exp simply skip
> the mips16 tests for r5900 without having to tell it explicitly about
> r5900.
> 
> Thanks,
> Matthew
> 
> 
> > The patch is working for the R5900 hard-fp mode. I've also used the
> > same, patched copy of GCC, to build the toolchain for the IOP (MIPS
> > R3000A, 32-bit MIPS I with no FPU) and it also builds correctly.
> >
> > If I should be writing to someone else specifically, could someone
> > please tell me who I should be writing to instead?
> >
> >
> > Thanks and regards,
> > -W Y
> >
> >
> >
> > On Tuesday, January 26, 2016 5:41 PM, Woon yung Liu
> <ysai187@yahoo.com> wrote:
> > Hi,
> >
> > I refer to the previous message by Juergen, regarding his patch to
> libgcc.
> > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01725.html
> >
> > As of now, libgcc (of GCC v5.3.0) still has the problem of building
> > support for both soft and hard floats, when there is no support for
> > hard floats by the R5900 (and hence resulting in the generation of
> recursive functions like extendsfdf2).
> >
> > That patch doesn't seem to have been committed. I would very much like
> > to help to see it get committed because GCC's support for the R5900 is
> > currently not suitable for PlayStation 2 development;
> > software-floating point emulation is severely detrimental to
> performance.
> > What else needs to be done first, before it can be accepted?
> >
> > Thanks and regards,
> > -W Y

Re: [MIPS r5900] libgcc floating point fixes

[Liu Woon Yung]

Hi again,

Thank you for the follow-up!

On 9/5/2016 8:22 PM, Matthew Fortune wrote:
> With a tweak to the new check in mips.c I think this is looking OK.
That's great to hear! Hopefully, we can put this old issue to rest soon.

> Do you have GCC FSF copyright assignment in place? Your change might be small
> enough not to need it but it assignment would make it easier.
No, I do not have one yet. I would appreciate it if you (or someone) 
would help me with obtaining one.
It will definitely make the submission of my (future) patches for the 
R5900's features easier.

Thanks and regards,
-W Y

Re: [MIPS r5900] libgcc floating point fixes

[Richard Sandiford]

"Jürgen Urban" <JuergenUrban@gmx.de> writes:
> The problem happens with the r5900 hard float configurations, e.g.:
> configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single
> --with-arch=r5900
> I created the attached patch which fixes this problem for r5900 and
> another problem explained later.
> The fixed code generates the following code which should be correct
> (mipsr5900el-ps2-elf):
>
> 00105440 <__extendsfdf2>:
>   105440:       27bdffc8        addiu   sp,sp,-56
>   105444:       27a40028        addiu   a0,sp,40
>   105448:       27a50018        addiu   a1,sp,24
>   10544c:       afbf0034        sw      ra,52(sp)
>   105450:       0c0417b5        jal     105ed4 <__unpack_f>
>   105454:       e7ac0028        swc1    $f12,40(sp)
>   105458:       8fa20024        lw      v0,36(sp)
>   10545c:       8fa40018        lw      a0,24(sp)
>   105460:       8fa5001c        lw      a1,28(sp)
>   105464:       8fa60020        lw      a2,32(sp)
>   105468:       00021882        srl     v1,v0,0x2
>   10546c:       00021780        sll     v0,v0,0x1e
>   105470:       afa20010        sw      v0,16(sp)
>   105474:       0c041789        jal     105e24 <__make_dp>
>   105478:       afa30014        sw      v1,20(sp)
>   10547c:       8fbf0034        lw      ra,52(sp)
>   105480:       03e00008        jr      ra
>   105484:       27bd0038        addiu   sp,sp,56
>
> The default targets mipsr5900el and mips64r5900el are not affected by
> the problem, because soft float is the default.
>
> It also seems that the same problem occurs with the following configuration:
> configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single
> I expected that this combination should work and a problem should
> already be detected. Can somebody confirm that the problem also occurs
> with default mipsel?

Although that configuration is in theory supported by GCC (said like that
because I don't know the state of the glibc support for single-float),
I don't think anyone uses it for any target other than r5900.  But you're
right that this is a --with-fpu=single thing rather than an r5900 thing,
so I don't think the patch is correct.  It should be keyed off whether
the target is single-float or double-float, which you can test by
checking whether the preprocessor macro __mips_single_float is defined.

Note that this won't really be correct for r5900 anyway because of its
non-IEEE FPU.  E.g. the soft-float routines will treat 0x7f800000 as
infinity and 0x7fffffff as a NaN, whereas for r5900 they should be treated
as normal numbers.

Thanks,
Richard

[MIPS r5900] libgcc floating point fixes

["Jürgen Urban"]

[-- Attachment #1: Type: text/plain, Size: 3801 bytes --]

Hello,

I found a problem in GCC on MIPS r5900: When printf() is used with type float, the converter function __extendsfdf2() is called. Parameters to printf() are always passed as double and not float. The function __extendsfdf2() calls itself to convert 32 bit float to 64 bit float. With Linux the __extendsfdf2() leads to a segfault when the stack limit is reached.
Here is the wrong code (mipsel-linux-gnu):

00402af0 <__extendsfdf2>:
  402af0:       3c1c0002        lui     gp,0x2
  402af4:       279c9b30        addiu   gp,gp,-25808
  402af8:       0399e021        addu    gp,gp,t9
  402afc:       8f9980a0        lw      t9,-32608(gp)  # Load pointer to __extendsfdf2 into t9
  402b00:       27bdffe0        addiu   sp,sp,-32
  402b04:       afbf001c        sw      ra,28(sp)
  402b08:       0320f809        jalr    t9             # Calls __extendsfdf2 (itself)
  402b0c:       afbc0010        sw      gp,16(sp)
  402b10:       8fbf001c        lw      ra,28(sp)
  402b14:       03e00008        jr      ra
  402b18:       27bd0020        addiu   sp,sp,32
  402b1c:       00000000        nop

The problem happens with the r5900 hard float configurations, e.g.:
configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single --with-arch=r5900
I created the attached patch which fixes this problem for r5900 and another problem explained later.
The fixed code generates the following code which should be correct (mipsr5900el-ps2-elf):

00105440 <__extendsfdf2>:
  105440:       27bdffc8        addiu   sp,sp,-56
  105444:       27a40028        addiu   a0,sp,40
  105448:       27a50018        addiu   a1,sp,24
  10544c:       afbf0034        sw      ra,52(sp)
  105450:       0c0417b5        jal     105ed4 <__unpack_f>
  105454:       e7ac0028        swc1    $f12,40(sp)
  105458:       8fa20024        lw      v0,36(sp)
  10545c:       8fa40018        lw      a0,24(sp)
  105460:       8fa5001c        lw      a1,28(sp)
  105464:       8fa60020        lw      a2,32(sp)
  105468:       00021882        srl     v1,v0,0x2
  10546c:       00021780        sll     v0,v0,0x1e
  105470:       afa20010        sw      v0,16(sp)
  105474:       0c041789        jal     105e24 <__make_dp>
  105478:       afa30014        sw      v1,20(sp)
  10547c:       8fbf0034        lw      ra,52(sp)
  105480:       03e00008        jr      ra
  105484:       27bd0038        addiu   sp,sp,56

The default targets mipsr5900el and mips64r5900el are not affected by the problem, because soft float is the default.

It also seems that the same problem occurs with the following configuration:
configure --target=mipsel-linux-gnu --with-float=hard --with-fpu=single
I expected that this combination should work and a problem should already be detected. Can somebody confirm that the problem also occurs with default mipsel?

The second part of the patch fixes the following configuration:
configure --target=mipsel-linux-gnu --with-arch=r5900
It disables the mips16 stuff in the libgcc. This can't be compiled on r5900. This was already disabled for targets mipsr5900*el. I detected the problem, because the buildroot project uses this style which leads to less problems with existing software (because "mipsel" or "mips64el" is hardcoded in most configure scripts and don't expect "mipsr5900el" or "mips64r5900el").

Can someone please add the patch to the official GCC repository?

I am not sure whether I fixed all self-calling implementations. Does somebody know a way of finding selfcalling implementations?

I tried to find a FPU testsuite, but the testsuites are not designed to test non-standard FPUs or use double instead of float. So there can be more problems with FPU on r5900 which I don't see at the moment.

Best regards
Jürgen Urban

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gcc-4.9.0-mips-ps2.patch --]
[-- Type: text/x-patch, Size: 2690 bytes --]

--- gcc-4.9.0/libgcc/config/t-hardfp-sf	1970-01-01 01:00:00.000000000 +0100
+++ gcc-4.9.0-patched/libgcc/config/t-hardfp-sf	2014-05-07 00:14:27.093320928 +0200
@@ -0,0 +1,32 @@
+# Copyright (C) 2014 Free Software Foundation, Inc.
+
+# This file is part of GCC.
+
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# <http://www.gnu.org/licenses/>.
+
+hardfp_float_modes := sf
+# di and ti are provided by libgcc2.c where needed.
+hardfp_int_modes := si
+hardfp_extensions :=
+hardfp_truncations :=
+
+# Emulate 64 bit float:
+FPBIT = true
+DPBIT = true
+# Don't build functions handled by 32 bit hardware:
+LIB2FUNCS_EXCLUDE = _addsub_sf _mul_sf _div_sf \
+    _fpcmp_parts_sf _compare_sf _eq_sf _ne_sf _gt_sf _ge_sf \
+    _lt_sf _le_sf _unord_sf _si_to_sf _sf_to_si _negate_sf \
+    _thenan_sf _sf_to_usi _usi_to_sf
--- gcc-4.9.0/libgcc/config.host	2014-03-27 16:40:31.000000000 +0100
+++ gcc-4.9.0-patched/libgcc/config.host	2014-05-07 00:10:16.565329373 +0200
@@ -140,11 +140,24 @@ microblaze*-*-*)
 	cpu_type=microblaze
 	;;
 mips*-*-*)
-	# All MIPS targets provide a full set of FP routines.
+	# All MIPS targets provide a full set of FP routines except r5900.
 	cpu_type=mips
 	tmake_file="mips/t-mips"
 	if test "${libgcc_cv_mips_hard_float}" = yes; then
-		tmake_file="${tmake_file} t-hardfp-sfdf t-hardfp"
+	    case ${host} in
+	      mips64r5900* | mipsr5900*)
+	        # r5900 doesn't support df.
+		tmake_file="${tmake_file} t-hardfp-sf t-hardfp"
+	        ;;
+	      *)
+	        if test x$with_arch = xr5900; then
+	            # r5900 doesn't support df.
+		    tmake_file="${tmake_file} t-hardfp-sf t-hardfp"
+		else
+		    tmake_file="${tmake_file} t-hardfp-sfdf t-hardfp"
+	        fi
+	        ;;
+	    esac
 	else
 		tmake_file="${tmake_file} t-softfp-sfdf"
 	fi
@@ -794,7 +807,9 @@ mips*-*-linux*)				# Linux MIPS, either
 	    # instructions that are not supported on r5900.
 	    ;;
 	  *)
-	    tmake_file="${tmake_file} mips/t-mips16 t-slibgcc-libgcc"
+	    if test x$with_arch != xr5900; then
+		tmake_file="${tmake_file} mips/t-mips16 t-slibgcc-libgcc"
+	    fi
 	    ;;
 	esac
 	md_unwind_header=mips/linux-unwind.h