On Sun, 2 Feb 2014, Richard Sandiford wrote: > This patch (finally!) moves MIPS over to the soft-fp routines. The main > advantage is that we now handle 128-bit long-double exceptions properly > on hard-float targets.
Thanks for doing this. At some point I intend to add soft-fp support for after-rounding tininess detection, so this can then get underflow exceptions exactly right (per IEEE 754, all binary floating-point operations need to detect tininess in the same way, and MIPS is an after-rounding architecture, and soft-fp only does before-rounding at present - this is also wrong for x86 __float128, as x86 is also after-rounding). I'll also update glibc (ports/sysdeps/mips/math-tests.h) to know that exceptions and rounding modes for long double are supported for MIPS with GCC >= 4.9 (once I've done the after-rounding support, otherwise some fma tests will fail). I note that you're not using t-softfp-excl. Logically, it's best to use the libgcc2.c functions in the cases where hardware floating point is involved (when they are providing conversions to/from DImode/TImode, and to/from unsigned, based on conversions to/from a narrower type or to/from signed, and the floating-point type involved is a hardware type), because that will be more efficient than a fully software implementation. But when building for a soft-float multilib, and in any case when TFmode is involved, it's best to use the soft-fp functions rather than the libgcc2.c versions. Thus: * For soft-float, what you have seems optimal. * For hard-float o32, using t-softfp-excl would be best. * For hard-float n32 and n64, what's optimal would be a hybrid the makefile code doesn't yet support, so would need custom handling in MIPS fragments; see above, and the t-softfp comment "This list is taken from mklibgcc.in and doesn't presently allow for 64-bit targets where si should become di and di should become ti.". How much this matters (and indeed how much it matters for hard-float o32) depends on which of the conversions involving SFmode / DFmode do actually end up using a libgcc function (for which the libgcc2.c version would be better than the soft-fp version). Obviously any change to this would best be tested including comparisons of the libgcc_s.so exported symbols before and after the patch, like you did for the present patch. -- Joseph S. Myers jos...@codesourcery.com
