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

[Colin Percival]

David Schultz wrote:
> On Wed, Mar 05, 2008, Colin Percival wrote:
>> David Schultz wrote:
>>> ... if we're going to go down this path, we ought to just bite
>>> the bullet and change npx.h and contrib/gcc/config/i386/freebsd.h
>>> to use 64-bit precision by default on i386.
>> Why would we want to randomly and pointlessly break things?  To quote
>> Kahan, "if a programmer asks for IEEE double-precision arithmetic, of
>> course that's what you should give him" -- double rounding is simply
>> not acceptable.
> 
> gcc/i386 doesn't correctly support IEEE 754 floating point no
> matter which option we choose. It's really a question of whether
> we want unexpected behavior for doubles or for long doubles.

As far as I can see, there's no question here.  C99 requires that
the "double" type matches the IEEE 754 64-bit double; but it allows
the "long double" type to be an IEEE 754 80-bit extended, a 128-bit
quadruple, a 64-bit double, or anything else which is at least as
good as a 64-bit double.

Setting the i387 FPU to 53-bit precision gives standards-compliant
behaviour whether people are using "double" or "long double".  Setting
it to 64-bit precision gives standards-compliant behaviour when people
are using long doubles, but not when people are using doubles.

> First, what you say above isn't quite right. Even IEEE 754R says
> that implementations should be allowed to use wider precision when
> available, but there are four cases where values are required to
> be rounded to the precision of the type: assignments, casts,
> function arguments, and function return values.

Yes and no.  Double rounding isn't allowed; so performing operations
with extended precision and then rounding to double precision later
is not a valid option.  The only way on the i387 to provide standards
compliant floating-point arithmetic is to have the FPU set to not use
the extra precision in the first place.

> The downside is that this breaks long doubles.

Except that it doesn't.  Using 53-bit precision for long doubles is
a perfectly valid and standards-compliant option.

Colin Percival