[MIPS r5900] libgcc floating point fixes

[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

Aw: [MIPS r5900] libgcc floating point fixes

["Jürgen Urban"]

Please don't ignore this, support for MIPS r5900 was already ignored for ~10 years. Just apply the patch when you don't know what I am talking about. The fix for mips16 is very important. The patch has impact only on MIPS r5900.

> Gesendet: Sonntag, 15. Juni 2014 um 22:08 Uhr
> Von: "Jürgen Urban" <JuergenUrban@gmx.de>
> An: gcc-patches@gcc.gnu.org
> Cc: JuergenUrban@gmx.de
> Betreff: [MIPS r5900] libgcc floating point fixes
>
> 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

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

Aw: Re: [MIPS r5900] libgcc floating point fixes

["Jürgen Urban"]

Hello Richard,

> "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.

Checking these macros seem to be too late, because it needs to be known at configure time and not at build time. The libgcc doesn't seem to be very flexible. It doesn't seem to provide different libraries for single and double float. The Linux kernel on the PS2 has support to switch between single and double float. For single float the hardware FPU is used and for double the FPU emulator gets activated. Currently it only checks whether the architecture is mips r5900 or not. For non r5900 the FPU emulator is activated. It seems that we also need to add something to the ELF file to specify the 32 bit or 64 bit for float. It would be good when it is not at a so complicated position as the soft vs hard float flag, because it needs to be read by the kernel when starting a ELF file. This way it would also be possible to emulate the r5900 FPU on a TX79 system. The TX79 is the same as r5900, but the FPU is 64 bit and compliant to IEEE 754.

> 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.

The code looked like it uses the configured floating point configuration for hard float, but you are right the conversion is not working in these cases.

I think there is no problem with the second part of the patch which disables t-mips16 for r5900. So could you commit the last part of the patch?

Best regards
Jürgen

RE: Re: [MIPS r5900] libgcc floating point fixes

[Matthew Fortune]

"Jürgen Urban" <JuergenUrban@gmx.de> writes:
> Hello Richard,
> 
> > "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.
> 
> Checking these macros seem to be too late, because it needs to be known at
> configure time and not at build time. The libgcc doesn't seem to be very

I believe the suggestion is to add some code to configure.ac to detect a
single-float configuration like the hard-float is detected and update your
patch accordingly with no need to reference r5900 at all:

case ${host} in
mips*-*-*)
  AC_CACHE_CHECK([whether the target is hard-float],
                 [libgcc_cv_mips_hard_float],
                 [AC_COMPILE_IFELSE(
    [#ifndef __mips_hard_float
     #error FOO
     #endif],
    [libgcc_cv_mips_hard_float=yes],
    [libgcc_cv_mips_hard_float=no])])
esac

> flexible. It doesn't seem to provide different libraries for single and

Single and double float would need to be supported as multilibs, it is generally
assumed that all libraries in the same folder follow a compatible ABI. Single
and double float ABIs are inherently incompatible.

> double float. The Linux kernel on the PS2 has support to switch between
> single and double float. For single float the hardware FPU is used and for

Just to confirm... The kernel has special handling for an ELF using r5900 arch
and then checks to see if it is single or double float? Is this something you
have recently developed outside of the mainline kernel or does it already exist.
I'm not aware of such logic in the MIPS kernel yet.

> double the FPU emulator gets activated. Currently it only checks whether the
> architecture is mips r5900 or not. For non r5900 the FPU emulator is
> activated. It seems that we also need to add something to the ELF file to
> specify the 32 bit or 64 bit for float. It would be good when it is not at a
> so complicated position as the soft vs hard float flag, because it needs to
> be read by the kernel when starting a ELF file. This way it would also be

I have a series of patches that will add this kind of support to the MIPS
ABI in the coming weeks for similar reasons but relating to O32 and double-float
ABI extensions. You will be able to directly hang off the changes once I commit
(testing is taking some time). There should be no need for extra changes to
gcc or binutils to get the information you need. Kernel changes to respond
to new ABI information are also in progress and will be easily extendable.

> possible to emulate the r5900 FPU on a TX79 system. The TX79 is the same as
> r5900, but the FPU is 64 bit and compliant to IEEE 754.
> 
> > 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.
> 
> The code looked like it uses the configured floating point configuration for
> hard float, but you are right the conversion is not working in these cases.
>
> I think there is no problem with the second part of the patch which disables
> t-mips16 for r5900. So could you commit the last part of the patch?

Are you looking to add support for a single-float FPU to a number of
packages as part of this? One thing that comes to mind would be libffi but the
double-precision ABIs are assumed to be the only ones used in Linux in a number
of places. Just trying to get a feel for your end goal out of curiosity.

Regards,
Matthew

RE: Re: [MIPS r5900] libgcc floating point fixes

["Jürgen Urban"]

> "Jürgen Urban" <JuergenUrban@gmx.de> writes:
> > Hello Richard,
> > 
> > > "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.
> > 
> > Checking these macros seem to be too late, because it needs to be known at
> > configure time and not at build time. The libgcc doesn't seem to be very
> 
> I believe the suggestion is to add some code to configure.ac to detect a
> single-float configuration like the hard-float is detected and update your
> patch accordingly with no need to reference r5900 at all:
> 
> case ${host} in
> mips*-*-*)
>   AC_CACHE_CHECK([whether the target is hard-float],
>                  [libgcc_cv_mips_hard_float],
>                  [AC_COMPILE_IFELSE(
>     [#ifndef __mips_hard_float
>      #error FOO
>      #endif],
>     [libgcc_cv_mips_hard_float=yes],
>     [libgcc_cv_mips_hard_float=no])])
> esac

I will check if I get something working.

> > flexible. It doesn't seem to provide different libraries for single and
> 
> Single and double float would need to be supported as multilibs, it is generally
> assumed that all libraries in the same folder follow a compatible ABI. Single
> and double float ABIs are inherently incompatible.
> 
> > double float. The Linux kernel on the PS2 has support to switch between
> > single and double float. For single float the hardware FPU is used and for
> 
> Just to confirm... The kernel has special handling for an ELF using r5900 arch
> and then checks to see if it is single or double float?

Yes, for checking for r5900 I have an implementation. I don't have an implementation for single and double float detection.

> Is this something you
> have recently developed outside of the mainline kernel or does it already exist.
> I'm not aware of such logic in the MIPS kernel yet.

Yes, this is developed in my kernel which currently is still based on Linux 2.6.35.4. I added a TIF_R5900FPU flag to thread_info.h. I plan that this will get part of the mainline kernel. As the patch is too large to get accepted, I need to change the binutils, so that sync.p will be added after or before the right instruction automatically.

> > double the FPU emulator gets activated. Currently it only checks whether the
> > architecture is mips r5900 or not. For non r5900 the FPU emulator is
> > activated. It seems that we also need to add something to the ELF file to
> > specify the 32 bit or 64 bit for float. It would be good when it is not at a
> > so complicated position as the soft vs hard float flag, because it needs to
> > be read by the kernel when starting a ELF file. This way it would also be
> 
> I have a series of patches that will add this kind of support to the MIPS
> ABI in the coming weeks for similar reasons but relating to O32 and double-float
> ABI extensions. You will be able to directly hang off the changes once I commit
> (testing is taking some time). There should be no need for extra changes to
> gcc or binutils to get the information you need. Kernel changes to respond
> to new ABI information are also in progress and will be easily extendable.
> 
> > possible to emulate the r5900 FPU on a TX79 system. The TX79 is the same as
> > r5900, but the FPU is 64 bit and compliant to IEEE 754.
> > 
> > > 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.
> > 
> > The code looked like it uses the configured floating point configuration for
> > hard float, but you are right the conversion is not working in these cases.
> >
> > I think there is no problem with the second part of the patch which disables
> > t-mips16 for r5900. So could you commit the last part of the patch?
> 
> Are you looking to add support for a single-float FPU to a number of
> packages as part of this? One thing that comes to mind would be libffi but the
> double-precision ABIs are assumed to be the only ones used in Linux in a number
> of places. Just trying to get a feel for your end goal out of curiosity.

The libffi doesn't look like that there is a change needed for floating point.
It is possible that it needs a change for TImode or for 2 or 3 of the other co-processors which are currently not under discussion.
The long term plan is to have 32 bit floating point operations compliant to IEEE 754 with ABI o32 and n32. Everything should stay inside gcc, libgcc and the kernel (i.e. Linux or PS2SDK). I want to fix it at the lowest level and not in any high level library. Fixes for high level libraries should also be high level (dmult vs __FLT_MAX_EXP__); i.e. there should be no change in a different package which is specific for MIPS. The type double should stay double and is handled without a problem when the FPU is 32 bit in ABI o32. The problem is only with the single/double conversion functions and the ABI n32.

Best regards
Jürgen

RE: Re: [MIPS r5900] libgcc floating point fixes

[Matthew Fortune]

"Jürgen Urban" <JuergenUrban@gmx.de>writes:
> > "Jürgen Urban" <JuergenUrban@gmx.de> writes:
> > > Hello Richard,
> > >
> > > > "Jürgen Urban" <JuergenUrban@gmx.de> writes:
> > Is this something you
> > have recently developed outside of the mainline kernel or does it already
> exist.
> > I'm not aware of such logic in the MIPS kernel yet.
> 
> Yes, this is developed in my kernel which currently is still based on Linux
> 2.6.35.4. I added a TIF_R5900FPU flag to thread_info.h. I plan that this
> will get part of the mainline kernel. As the patch is too large to get
> accepted, I need to change the binutils, so that sync.p will be added after
> or before the right instruction automatically.

Is the TIF_R5900FPU flag to do something more than just change the register
model used by the FPU emulator or does it do something more/less? I'm afraid
I don’t know the significance of the sync.p.

> > > double the FPU emulator gets activated. Currently it only checks whether
> the
> > > architecture is mips r5900 or not. For non r5900 the FPU emulator is
> > > activated. It seems that we also need to add something to the ELF file
> to
> > > specify the 32 bit or 64 bit for float. It would be good when it is not
> at a
> > > so complicated position as the soft vs hard float flag, because it needs
> to
> > > be read by the kernel when starting a ELF file. This way it would also
> be
> >
> > I have a series of patches that will add this kind of support to the MIPS
> > ABI in the coming weeks for similar reasons but relating to O32 and
> double-float
> > ABI extensions. You will be able to directly hang off the changes once I
> commit
> > (testing is taking some time). There should be no need for extra changes
> to
> > gcc or binutils to get the information you need. Kernel changes to respond
> > to new ABI information are also in progress and will be easily extendable.
> >
> > > possible to emulate the r5900 FPU on a TX79 system. The TX79 is the same
> as
> > > r5900, but the FPU is 64 bit and compliant to IEEE 754.
> > >
> > > > 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.
> > >
> > > The code looked like it uses the configured floating point configuration
> for
> > > hard float, but you are right the conversion is not working in these
> cases.
> > >
> > > I think there is no problem with the second part of the patch which
> disables
> > > t-mips16 for r5900. So could you commit the last part of the patch?
> >
> > Are you looking to add support for a single-float FPU to a number of
> > packages as part of this? One thing that comes to mind would be libffi but
> the
> > double-precision ABIs are assumed to be the only ones used in Linux in a
> number
> > of places. Just trying to get a feel for your end goal out of curiosity.
> 
> The libffi doesn't look like that there is a change needed for floating
> point.

Libffi and most other hand crafted code for linux are written to follow the
standard double-precision O32/N32 ABI. The single-precision variants are
link-incompatible as they change the calling convention. I.e. when you pass
a double-precision value using a single-precision calling-convention then it
gets passed in GPRs instead of FPRs.

> It is possible that it needs a change for TImode or for 2 or 3 of the other
> co-processors which are currently not under discussion.
> The long term plan is to have 32 bit floating point operations compliant to
> IEEE 754 with ABI o32 and n32. Everything should stay inside gcc, libgcc and
> the kernel (i.e. Linux or PS2SDK). I want to fix it at the lowest level and
> not in any high level library.

Due to the calling convention change you won't be able to restrict the work
to just the toolchain and kernel. MIPS linux theoretically supports two ABI
extensions 'hard-float (double-precision)' and soft-float. I have a feeling
that the soft-float extension is not supported everywhere but may be a better
start point for what you want to achieve, i.e. use a soft-float calling
convention but add support for using FPU instructions at the same time. This
would be akin to arm's softfp float-abi.

> Fixes for high level libraries should also be
> high level (dmult vs __FLT_MAX_EXP__); i.e. there should be no change in a
> different package which is specific for MIPS. The type double should stay
> double and is handled without a problem when the FPU is 32 bit in ABI o32.
> The problem is only with the single/double conversion functions and the ABI
> n32.

I didn't quite follow why you specifically say n32 in the last sentence...
What is harder to fix about n32 than o32?

Thanks,
Matthew

Aw: RE: Re: [MIPS r5900] libgcc floating point fixes

["Jürgen Urban"]

> "Jürgen Urban" <JuergenUrban@gmx.de>writes:
> > > "Jürgen Urban" <JuergenUrban@gmx.de> writes:
> > > > Hello Richard,
> > > >
> > > > > "Jürgen Urban" <JuergenUrban@gmx.de> writes:
> > > Is this something you
> > > have recently developed outside of the mainline kernel or does it already
> > exist.
> > > I'm not aware of such logic in the MIPS kernel yet.
> > 
> > Yes, this is developed in my kernel which currently is still based on Linux
> > 2.6.35.4. I added a TIF_R5900FPU flag to thread_info.h. I plan that this
> > will get part of the mainline kernel. As the patch is too large to get
> > accepted, I need to change the binutils, so that sync.p will be added after
> > or before the right instruction automatically.
> 
> Is the TIF_R5900FPU flag to do something more than just change the register
> model used by the FPU emulator or does it do something more/less?

Currently it just enables or disables the FPU. When FPU is disabled the software emulation is used.

> I'm afraid I don’t know the significance of the sync.p.
> 
> > > > double the FPU emulator gets activated. Currently it only checks whether
> > the
> > > > architecture is mips r5900 or not. For non r5900 the FPU emulator is
> > > > activated. It seems that we also need to add something to the ELF file
> > to
> > > > specify the 32 bit or 64 bit for float. It would be good when it is not
> > at a
> > > > so complicated position as the soft vs hard float flag, because it needs
> > to
> > > > be read by the kernel when starting a ELF file. This way it would also
> > be
> > >
> > > I have a series of patches that will add this kind of support to the MIPS
> > > ABI in the coming weeks for similar reasons but relating to O32 and
> > double-float
> > > ABI extensions. You will be able to directly hang off the changes once I
> > commit
> > > (testing is taking some time). There should be no need for extra changes
> > to
> > > gcc or binutils to get the information you need. Kernel changes to respond
> > > to new ABI information are also in progress and will be easily extendable.
> > >
> > > > possible to emulate the r5900 FPU on a TX79 system. The TX79 is the same
> > as
> > > > r5900, but the FPU is 64 bit and compliant to IEEE 754.
> > > >
> > > > > 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.
> > > >
> > > > The code looked like it uses the configured floating point configuration
> > for
> > > > hard float, but you are right the conversion is not working in these
> > cases.
> > > >
> > > > I think there is no problem with the second part of the patch which
> > disables
> > > > t-mips16 for r5900. So could you commit the last part of the patch?
> > >
> > > Are you looking to add support for a single-float FPU to a number of
> > > packages as part of this? One thing that comes to mind would be libffi but
> > the
> > > double-precision ABIs are assumed to be the only ones used in Linux in a
> > number
> > > of places. Just trying to get a feel for your end goal out of curiosity.
> > 
> > The libffi doesn't look like that there is a change needed for floating
> > point.
> 
> Libffi and most other hand crafted code for linux are written to follow the
> standard double-precision O32/N32 ABI. The single-precision variants are
> link-incompatible as they change the calling convention. I.e. when you pass
> a double-precision value using a single-precision calling-convention then it
> gets passed in GPRs instead of FPRs.
> 
> > It is possible that it needs a change for TImode or for 2 or 3 of the other
> > co-processors which are currently not under discussion.
> > The long term plan is to have 32 bit floating point operations compliant to
> > IEEE 754 with ABI o32 and n32. Everything should stay inside gcc, libgcc and
> > the kernel (i.e. Linux or PS2SDK). I want to fix it at the lowest level and
> > not in any high level library.
> 
> Due to the calling convention change you won't be able to restrict the work
> to just the toolchain and kernel. MIPS linux theoretically supports two ABI
> extensions 'hard-float (double-precision)' and soft-float. I have a feeling
> that the soft-float extension is not supported everywhere but may be a better
> start point for what you want to achieve, i.e. use a soft-float calling
> convention but add support for using FPU instructions at the same time. This
> would be akin to arm's softfp float-abi.
> 
> > Fixes for high level libraries should also be
> > high level (dmult vs __FLT_MAX_EXP__); i.e. there should be no change in a
> > different package which is specific for MIPS. The type double should stay
> > double and is handled without a problem when the FPU is 32 bit in ABI o32.
> > The problem is only with the single/double conversion functions and the ABI
> > n32.
> 
> I didn't quite follow why you specifically say n32 in the last sentence...
> What is harder to fix about n32 than o32?

"-msingle-float" with n32 creates 64 bit FPU instructions like dmtc1 and dmfc1. So I can't compile it for r5900. When I disable it, I get internal compiler errors.

Best regards
Jürgen

RE: RE: Re: [MIPS r5900] libgcc floating point fixes

[Matthew Fortune]

> > > Fixes for high level libraries should also be
> > > high level (dmult vs __FLT_MAX_EXP__); i.e. there should be no change in
> a
> > > different package which is specific for MIPS. The type double should
> stay
> > > double and is handled without a problem when the FPU is 32 bit in ABI
> o32.
> > > The problem is only with the single/double conversion functions and the
> ABI
> > > n32.
> >
> > I didn't quite follow why you specifically say n32 in the last sentence...
> > What is harder to fix about n32 than o32?
> 
> "-msingle-float" with n32 creates 64 bit FPU instructions like dmtc1 and
> dmfc1. So I can't compile it for r5900. When I disable it, I get internal
> compiler errors.

That certainly seems like a bug. Can you file a bug report for that with
a test case? I'll try and handle it when I next work on the single-float
support in GCC.

Did you manage to get the libgcc patch reworked to be independent of r5900?

Thanks,
Matthew

Aw: RE: RE: Re: [MIPS r5900] libgcc floating point fixes

["Jürgen Urban"]

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

Hello,

> > > > Fixes for high level libraries should also be
> > > > high level (dmult vs __FLT_MAX_EXP__); i.e. there should be no change in
> > a
> > > > different package which is specific for MIPS. The type double should
> > stay
> > > > double and is handled without a problem when the FPU is 32 bit in ABI
> > o32.
> > > > The problem is only with the single/double conversion functions and the
> > ABI
> > > > n32.
> > >
> > > I didn't quite follow why you specifically say n32 in the last sentence...
> > > What is harder to fix about n32 than o32?
> > 
> > "-msingle-float" with n32 creates 64 bit FPU instructions like dmtc1 and
> > dmfc1. So I can't compile it for r5900. When I disable it, I get internal
> > compiler errors.
> 
> That certainly seems like a bug. Can you file a bug report for that with
> a test case? I'll try and handle it when I next work on the single-float
> support in GCC.

I added the bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61983
 
> Did you manage to get the libgcc patch reworked to be independent of r5900?

I needed to get my build environment in a state where I can change the code. I needed to test building the toolchain for 14 different MIPS configurations. I tested that 7 configurations build something where floating point calculations are correct. I needed to use my own tests for this, because I didn't find any testsuite which does it correctly.

I attached the new version of the patch which I tested with and without the FPU emulation on the MIPS r5900; i.e. I didn't tested with a normal MIPS, just what my Linux kernel emulates on r5900.
When I compile for mipsel ABI o32 with -mhard-float and -msingle-fpu, It get the warning:

Warning: float register should be even, was 1.

I would say the warning is wrong, because odd FPU registers are available.

Best regards
Jürgen Urban

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 950-mips-r5900.patch --]
[-- Type: text/x-patch, Size: 5813 bytes --]

diff -Nurp gcc-4.9.0/libgcc/config/t-hardfp-sf gcc-4.9.0-patched/libgcc/config/t-hardfp-sf
--- 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-07-31 22:05:24.177280902 +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
diff -Nurp gcc-4.9.0/libgcc/config.host gcc-4.9.0-patched/libgcc/config.host
--- gcc-4.9.0/libgcc/config.host	2014-03-27 16:40:31.000000000 +0100
+++ gcc-4.9.0-patched/libgcc/config.host	2014-07-31 23:21:42.093280358 +0200
@@ -144,7 +144,11 @@ mips*-*-*)
 	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"
+	    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
@@ -794,13 +798,18 @@ 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
 	;;
 mips*-sde-elf*)
-	tmake_file="$tmake_file mips/t-crtstuff mips/t-mips16"
+	tmake_file="$tmake_file mips/t-crtstuff"
+	if test x$with_arch != xr5900; then
+		tmake_file="$tmake_file mips/t-mips16"
+	fi
 	case "${with_newlib}" in
 	  yes)
 	    # newlib / libgloss.
@@ -828,7 +837,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 x$with_arch != xr5900; then
+		tmake_file="$tmake_file mips/t-mips16"
+	fi
 	extra_parts="$extra_parts crti.o crtn.o"
 	;;
 mipsr5900-*-elf* | mipsr5900el-*-elf*)
@@ -836,7 +848,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 x$with_arch != xr5900; then
+		tmake_file="$tmake_file mips/t-mips16"
+	fi
 	extra_parts="$extra_parts crti.o crtn.o"
 	;;
 mips64r5900-*-elf* | mips64r5900el-*-elf*)
@@ -852,7 +867,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 x$with_arch != xr5900; then
+		tmake_file="$tmake_file mips/t-mips16"
+	fi
 	extra_parts="$extra_parts crti.o crtn.o"
 	;;
 mips-wrs-vxworks)
diff -Nurp gcc-4.9.0/libgcc/configure.ac gcc-4.9.0-patched/libgcc/configure.ac
--- gcc-4.9.0/libgcc/configure.ac	2014-02-07 08:46:34.000000000 +0100
+++ gcc-4.9.0-patched/libgcc/configure.ac	2014-07-31 23:07:46.401280455 +0200
@@ -302,6 +302,14 @@ 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])])
 esac
 
 # Collect host-machine-specific information.
--- gcc-4.9.0/libgcc/configure	2014-08-03 15:54:04.089096533 +0200
+++ gcc-4.9.0/libgcc/configure	2014-08-03 15:54:17.641096787 +0200
@@ -4352,6 +4352,26 @@ 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; }
 esac
 
 # Collect host-machine-specific information.

RE: RE: RE: Re: [MIPS r5900] libgcc floating point fixes

[Matthew Fortune]

> > > > What is harder to fix about n32 than o32?
> > >
> > > "-msingle-float" with n32 creates 64 bit FPU instructions like dmtc1 and
> > > dmfc1. So I can't compile it for r5900. When I disable it, I get
> internal
> > > compiler errors.
> >
> > That certainly seems like a bug. Can you file a bug report for that with
> > a test case? I'll try and handle it when I next work on the single-float
> > support in GCC.
> 
> I added the bug report:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61983

Thanks.

> > Did you manage to get the libgcc patch reworked to be independent of
> r5900?
> 
> I needed to get my build environment in a state where I can change the code.
> I needed to test building the toolchain for 14 different MIPS
> configurations. I tested that 7 configurations build something where
> floating point calculations are correct. I needed to use my own tests for
> this, because I didn't find any testsuite which does it correctly.
> 
> I attached the new version of the patch which I tested with and without the
> FPU emulation on the MIPS r5900; i.e. I didn't tested with a normal MIPS,
> just what my Linux kernel emulates on r5900.

This seems better.

> When I compile for mipsel ABI o32 with -mhard-float and -msingle-fpu, It get
> the warning:
> 
> Warning: float register should be even, was 1.
> 
> I would say the warning is wrong, because odd FPU registers are available.

This is wrong but this is the area which is in flux at the moment. Can you
confirm which version of binutils you are using? Single-float support from both
GCC and binutils has been slightly inconsistent for a while and recent changes
to binutils have exposed the differences.

Matthew

RE: RE: RE: Re: [MIPS r5900] libgcc floating point fixes

["Jürgen Urban"]

> > When I compile for mipsel ABI o32 with -mhard-float and -msingle-fpu, It get
> > the warning:
> > 
> > Warning: float register should be even, was 1.
> > 
> > I would say the warning is wrong, because odd FPU registers are available.
> 
> This is wrong but this is the area which is in flux at the moment. Can you
> confirm which version of binutils you are using? Single-float support from both
> GCC and binutils has been slightly inconsistent for a while and recent changes
> to binutils have exposed the differences.

I used binutils 2.24.

Best regards
Jürgen