* [MIPS r5900] libgcc floating point fixes
@ 2014-06-15 20:08 "Jürgen Urban"
2014-06-24 21:16 ` Aw: " "Jürgen Urban"
2014-07-14 10:25 ` Richard Sandiford
0 siblings, 2 replies; 12+ messages in thread
From: "Jürgen Urban" @ 2014-06-15 20:08 UTC (permalink / raw)
To: gcc-patches; +Cc: JuergenUrban
[-- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Aw: [MIPS r5900] libgcc floating point fixes
2014-06-15 20:08 [MIPS r5900] libgcc floating point fixes "Jürgen Urban"
@ 2014-06-24 21:16 ` "Jürgen Urban"
2014-07-14 10:25 ` Richard Sandiford
1 sibling, 0 replies; 12+ messages in thread
From: "Jürgen Urban" @ 2014-06-24 21:16 UTC (permalink / raw)
To: gcc-patches; +Cc: JuergenUrban
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [MIPS r5900] libgcc floating point fixes
2014-06-15 20:08 [MIPS r5900] libgcc floating point fixes "Jürgen Urban"
2014-06-24 21:16 ` Aw: " "Jürgen Urban"
@ 2014-07-14 10:25 ` Richard Sandiford
2014-07-18 19:16 ` Aw: " "Jürgen Urban"
1 sibling, 1 reply; 12+ messages in thread
From: Richard Sandiford @ 2014-07-14 10:25 UTC (permalink / raw)
To: Jürgen Urban; +Cc: gcc-patches
"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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Aw: Re: [MIPS r5900] libgcc floating point fixes
2014-07-14 10:25 ` Richard Sandiford
@ 2014-07-18 19:16 ` "Jürgen Urban"
2014-07-18 21:07 ` Matthew Fortune
0 siblings, 1 reply; 12+ messages in thread
From: "Jürgen Urban" @ 2014-07-18 19:16 UTC (permalink / raw)
To: Richard Sandiford; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Re: [MIPS r5900] libgcc floating point fixes
2014-07-18 19:16 ` Aw: " "Jürgen Urban"
@ 2014-07-18 21:07 ` Matthew Fortune
2014-07-20 17:06 ` "Jürgen Urban"
0 siblings, 1 reply; 12+ messages in thread
From: Matthew Fortune @ 2014-07-18 21:07 UTC (permalink / raw)
To: "Jürgen Urban", Richard Sandiford; +Cc: gcc-patches
"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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Re: [MIPS r5900] libgcc floating point fixes
2014-07-18 21:07 ` Matthew Fortune
@ 2014-07-20 17:06 ` "Jürgen Urban"
2014-07-21 6:25 ` Matthew Fortune
0 siblings, 1 reply; 12+ messages in thread
From: "Jürgen Urban" @ 2014-07-20 17:06 UTC (permalink / raw)
To: Matthew Fortune; +Cc: Richard Sandiford, gcc-patches
> "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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Re: [MIPS r5900] libgcc floating point fixes
2014-07-20 17:06 ` "Jürgen Urban"
@ 2014-07-21 6:25 ` Matthew Fortune
2014-07-28 1:08 ` Aw: " "Jürgen Urban"
0 siblings, 1 reply; 12+ messages in thread
From: Matthew Fortune @ 2014-07-21 6:25 UTC (permalink / raw)
To: "Jürgen Urban"; +Cc: Richard Sandiford, gcc-patches
"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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Aw: RE: Re: [MIPS r5900] libgcc floating point fixes
2014-07-21 6:25 ` Matthew Fortune
@ 2014-07-28 1:08 ` "Jürgen Urban"
2014-07-28 8:49 ` Matthew Fortune
0 siblings, 1 reply; 12+ messages in thread
From: "Jürgen Urban" @ 2014-07-28 1:08 UTC (permalink / raw)
To: Matthew Fortune; +Cc: Richard Sandiford, gcc-patches
> "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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: RE: Re: [MIPS r5900] libgcc floating point fixes
2014-07-28 1:08 ` Aw: " "Jürgen Urban"
@ 2014-07-28 8:49 ` Matthew Fortune
2014-08-03 19:39 ` Aw: " "Jürgen Urban"
0 siblings, 1 reply; 12+ messages in thread
From: Matthew Fortune @ 2014-07-28 8:49 UTC (permalink / raw)
To: "Jürgen Urban"; +Cc: Richard Sandiford, gcc-patches
> > > 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Aw: RE: RE: Re: [MIPS r5900] libgcc floating point fixes
2014-07-28 8:49 ` Matthew Fortune
@ 2014-08-03 19:39 ` "Jürgen Urban"
2014-08-18 9:59 ` Matthew Fortune
0 siblings, 1 reply; 12+ messages in thread
From: "Jürgen Urban" @ 2014-08-03 19:39 UTC (permalink / raw)
To: Matthew Fortune; +Cc: Richard Sandiford, gcc-patches
[-- 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: RE: RE: Re: [MIPS r5900] libgcc floating point fixes
2014-08-03 19:39 ` Aw: " "Jürgen Urban"
@ 2014-08-18 9:59 ` Matthew Fortune
2014-08-18 16:08 ` "Jürgen Urban"
0 siblings, 1 reply; 12+ messages in thread
From: Matthew Fortune @ 2014-08-18 9:59 UTC (permalink / raw)
To: "Jürgen Urban"
Cc: Richard Sandiford, gcc-patches, Eric Christopher (echristo@gmail.com)
> > > > 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: RE: RE: Re: [MIPS r5900] libgcc floating point fixes
2014-08-18 9:59 ` Matthew Fortune
@ 2014-08-18 16:08 ` "Jürgen Urban"
0 siblings, 0 replies; 12+ messages in thread
From: "Jürgen Urban" @ 2014-08-18 16:08 UTC (permalink / raw)
To: Matthew Fortune
Cc: Richard Sandiford, gcc-patches, Eric Christopher (echristo@gmail.com)
> > 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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-08-18 16:08 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-15 20:08 [MIPS r5900] libgcc floating point fixes "Jürgen Urban"
2014-06-24 21:16 ` Aw: " "Jürgen Urban"
2014-07-14 10:25 ` Richard Sandiford
2014-07-18 19:16 ` Aw: " "Jürgen Urban"
2014-07-18 21:07 ` Matthew Fortune
2014-07-20 17:06 ` "Jürgen Urban"
2014-07-21 6:25 ` Matthew Fortune
2014-07-28 1:08 ` Aw: " "Jürgen Urban"
2014-07-28 8:49 ` Matthew Fortune
2014-08-03 19:39 ` Aw: " "Jürgen Urban"
2014-08-18 9:59 ` Matthew Fortune
2014-08-18 16:08 ` "Jürgen Urban"
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).