Re: real.c implementation

[dewar at gnat dot com (Robert Dewar)]

> The reason for our surprise is that you chose not to fix gcc but to
> duplicate functionality instead.

Sorry I don't understand.

The Ada front end is required to have much greater capability than the
GCC back end, because it is required to evaluate precisely accurately
all static floating-point expressions (even if the results are far outside
the range of numbers representable in machine floating-point). That's a
semantic requirement in Ada, for example, the following is legal:

   a : constant := 1.3E+786666123;
   b : constant := 1.7E+91234234234;
   c : constant := a/b;

c must be exactly represented at compile time without any overflow.

Second, with regard to decimal constants, we don't want to generate constants
in decimal in any case, because assemblers cannot be trusted. So when we did
generate in decimal, we noticed two things, GCC did not always get denormals
right (there may have been other problems, but I can't remember), and in any
case assemblers did not do the conversions last bit accurate with the 
required rounding mode.

"fix gcc" here is not well defined, there is no clear semantic spec of what
gcc is expected to do here (most languages don't care about precise float
semantics, certainly C and C++ did not in the past, so this is not so
surprising). Even if there were a clear spec, it would be surprising if
it exactly matched the very detailed rules in Annex G of the Ada standard
in all cases.