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
On Oct 10, 2007, at 08:25, Richard Sandiford wrote:
Your reply seems to be about why it's useful to have a macro that
provides the widest efficient floating-point type. For avoidance
of doubt, I can certainly appreciate that such a thing is useful.
I'm just not sure why it's needed for correctness. Olivier said:
...
I was trying to understand why the runtime library raises a constraint
error. Is it simply that the library only supports software floating
point for single and double precision (but supports hardware floating
point for wider types)? Is it not possible to construct a version
of the
Ada test above that forces the use of the equivalent of C "long
double"?
If so, would that fail in the same way, or don't we care?
As I'm travelling tomorrow, and don't have easy access to
a MIPS system right now, I won't have enough time
today to debug this issue in detail before next week.
There's one of two possibilities:
- the GNAT run time doesn't handle 128-bit float properly
- the 128-bit float doesn't have sane numerical semantics
As we haven't yet ported GNAT to a system with 128-bit hardware
floating point, it is very possible that some adaptations are
necessary. In fact, that's certainly the case.
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.
I 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.
It seems on the fact of it (to a non-Ada expert, of course) that
given:
get_target_long_double_size really ought to be using something called
ADA_LONG_DOUBLE_TYPE_SIZE, given that it isn't always the same as
LONG_DOUBLE_TYPE_SIZE.
Yes, there definitely is room for improvement here.
It's on my to do list.
-Geert