[PATCH] define WIDEST_HARDWARE_FP_SIZE on mips
Richard Sandiford
rdsandiford@googlemail.com
Wed Mar 4 22:18:00 GMT 2009
Geert Bosch <bosch@adacore.com> writes:
> As I indicated earlier, I think WIDEST_HARDWARE_FP_SIZE should indeed
> reflect the truth (so, should be 0 for software float, or 32 if only
> single precision is supported in HW).
OK, thanks.
> For Ada, we'll then replace uses of WIDEST_HARDWARE_FP_SIZE with an
> expression that takes the maximum of long_float_type_size and
> WIDEST_HARDWARE_FP_SIZE for the size of Long_Long_Float.
We're then back to the idea that "long double" can only be bigger
than "double" if the support is coming from some underlying "hardware".
But both you and Laurent seem to agree that this isn't actually a language
requirement, and I don't see how it makes sense in all cases. Many 64-bit
MIPS processors lack an FPU, but can (and do) still provide an n32 and
n64 environment that has support for 32-bit, 64-bit _and_ 128-bit long
double. If plain 64-bit double is implemented in software, why is it
automatically wrong to use the 128-bit long double support for
Long_Long_Float?
Please consider adding a new macro instead. Like I say, I think it's a
really bad idea to have a part of the ABI (or at least the API) depend
indirectly on a tuning macro. I.e. something like:
#ifndef ADA_LONG_DOUBLE_TYPE_SIZE
#define ADA_LONG_DOUBLE_TYPE_SIZE LONG_DOUBLE_TYPE_SIZE
#endif
Richard
More information about the Gcc-patches
mailing list