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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
