This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


Geert Bosch <> writes:
> On Oct 9, 2007, at 16:01, Richard Sandiford wrote:
>> Hmm.  Do you mean that GNAT doesn't support software floating point?
>> In other words, would this also happen on -msoft-float targets for
>> (I hope this doesn't sound awkward.  I'm just trying to understand the
>> issue better.)
> GNAT does support software floating point.
> The WIDEST_HARDWARE_FP_SIZE is there to prevent implicit
> use of software floating point for the widest FP types.
> Most targets claiming support for 128-bit floating point
> do so in ways that would make them unsuitable for use
> by Ada programs.
> A standard idiom in Ada is to declare types with the
> maximum floating-point precision supported, like:
>    type My_Float is new digits System.Max_Digits;
> One of the reasons for declaring such a type is to prevent
> implicit extra precision due to the FPU using wider
> hardware registers such as happens with x87 and IEEE
> single or double precision. Using the widest hardware
> type, every operation is correctly rounded to a machine
> number. This is an important property for numerical analysis.
> Sometimes, 128-bit types are implemented using non-IEEE
> semantics with very poor numerical properties ("double double").
> Another reason is to use the widest HW FP type is get the
> best accuracy that is still efficient. Many Ada applications
> are used in  strict real-time environments, and it would
> be disastrous to have performance of certain calculations
> drop down a  cliff because the compiler decides to use
> a 128-bit soft-float type, instead of a 64-bit or 80-bit hardware
> type. The performance difference here would be about 2 to
> 3 orders of magnitude.

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:

For instance, the test below is expected to output " +Inf*******".

On Irix 6.5, it currently raises a constraint_error exception from a
runtime library unit instead.

  << with Ada.Text_IO;

     procedure T is
       N : Float := 2.0;
       N := N ** 256;

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?

>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.

It seems on the fact of it (to a non-Ada expert, of course) that given:

get_target_float_size (void)
  return fp_prec_to_size (FLOAT_TYPE_SIZE);

get_target_double_size (void)
  return fp_prec_to_size (DOUBLE_TYPE_SIZE);

get_target_long_double_size (void)
  return fp_prec_to_size (WIDEST_HARDWARE_FP_SIZE);

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]