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

[David Schultz]

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.

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. C99 has a subset
of these requirements, but it's pretty clear that the C99 authors
were confused about some of the details.

gcc doesn't get any of this right. FreeBSD/i386 fixes the problem
for /doubles/ by setting the i387 to use 53-bit precision. The
downside is that this breaks long doubles. 15 years ago, this was
clearly the right thing to do, because we had a double precision
libm that would break when gcc got things wrong, and no long
double support anyway. Now we have a bunch of long double math
functions that have problems as a result of the reduced precision.
Furthermore, since gcc is the 800-pound gorilla here, many
programmers have grown accustomed to its shortcomings.