[PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Olivier Hainque]

Richard Sandiford wrote:
> The open question (to me) is why Olivier's original testcase failed
> with 128-bit long double.  I'm not sure anyone has really explained that.

 My limited understanding is basically that anything > 64 bit isn't
 supported for a bunch of reasons shared between the compiler and the
 Ada runtime library. Geert could tell much more about this and provided
 a number of extra details already.

 I also understand there's no mandate to support wide formats that
 don't correspond to hardware capabilities, and that
 WIDEST_HARDWARE_FP_SIZE was introduced for this purpose.
 
 IIRC, the original thread suggested we refine the suggested
 definition, hmm, right:

 http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00587.html

 Richard S wrote:

 << From a MIPS perspective, it's also counterintuitive for 
    WIDEST_HARDWARE_FP_SIZE to be 64 even for -msingle-float
    and -msoft-float targets (rather than 32 and 0 respectively).
    I can understand that 0 and 32 would be wrong given the way
    the macro is used in ada/targtyps.c, but it seems that Ada is
    using this macro for correctness -- and even to control an aspect
    of the API and ABI -- whereas libgcc2.c is using it for optimisation.
 >>

 Geert replied:

 << It definitely would be reasonable to set this to 32 and 0
    for -msingle-float and -msoft-float targets. Yes, that would
    mean we'd have to change targtypes.c, but that's fine.
    Especially with -msingle-float this would seem a clear improvement.
 >>

 I could interepret WIDEST_HARDWARE_FP_SIZE in slightly different manners
 so either way (constant 64 or refined variant) is fine with me.

 Geert ?