This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips
- From: Laurent GUERBY <laurent at guerby dot net>
- To: Olivier Hainque <hainque at adacore dot com>
- Cc: Geert Bosch <bosch at adacore dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, rdsandiford at googlemail dot com
- Date: Wed, 04 Mar 2009 11:19:10 +0100
- Subject: Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips
- References: <20071008085929.GA31575@cardhu.act-europe.fr> <87ir5ggirc.fsf@firetop.home> <FB24B712-F65B-4BB9-B360-4B4570C7FE3C@adacore.com> <87ve9ff96r.fsf@firetop.home> <7C2C6C26-1CF3-4304-B9E3-A33DA1C7B2C6@adacore.com> <1236015011.11347.800.camel@localhost> <873advn0uy.fsf@firetop.home> <20090303094510.GA13135@cardhu.act-europe.fr>
FWIW your mips.h patch cured the cxg failures
I observed before:
http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00388.html
I restested only abi=n32 but the result should be similar
on abi=64.
Laurent
On Tue, 2009-03-03 at 10:45 +0100, Olivier Hainque wrote:
> 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 ?
>
>
>
>
>
>