cvs commit: src/sys/i386/include _types.h

[Colin Percival]

David Schultz wrote:
> On Thu, Mar 06, 2008, Colin Percival wrote:
>>   explicit or implicit final destination. When a variable with a declared format
>>                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   is a final destination, as in format conversion to a variable, that declared
>>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   format of that variable governs its rounding. The format of an implicit
>>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>   destination, or of an explicit destination without a declared format, is
>>   defined by language standard expression evaluation rules.
> 
> I think you missed the point about implicit destinations.

No.  Another quote:
  2.2.14 destination: The location for the result of an operation upon one or
  more operands. A destination might be either explicitly designated by the user
  or implicitly supplied by the system (for example, intermediate results in
  subexpressions or arguments for procedures). [...]

Implicit destinations are things like the (x * y) in "x * y - 1.0" or in
"sqrt(x * y)".

> The register is an implicit destination. IEEE 754R explains this
> in more detail.

Really?   I can't find any such statements... quite the contrary.

> All that is guaranteed in this case is that the
> wider register value is never substituted for z in subsequent
> operations. (This is part of what gcc gets wrong.)

If IEEE754R intended that "z = x + y" with x, y, and z all doubles did not
guarantee reproducible results across compliant platforms, why does it say
exactly the opposite?

>> What standard states that those bounds are required (or can be relied upon
>> when proving that code is correct)?  [...]
> 
> There's no standard requirements, but a max error < 0.50x ulps
> implies correct rounding nearly all of the time, and that's what
> libm attempts to provide. This is about the best you can do
> without resorting to multiprecision arithmetic in the hard cases,
> so it seems like a good tradeoff between accuracy and ease of
> implementation. When substantially faster and slightly less
> accurate MD implementations are available, that changes the
> tradeoff.

Sure.  As I said before, more accurate transcendental functions are always
nice to have, but they are not *required* by any standard.  Correctly-rounded
arithmetic operations *are* required.

Colin Percival