Date: Wed, 05 Mar 2008 21:18:55 -0800 From: Colin Percival <cperciva@freebsd.org> To: Colin Percival <cperciva@FreeBSD.ORG>, Peter Jeremy <peterjeremy@optushome.com.au>, Bruce Evans <bde@FreeBSD.ORG>, src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/include _types.h Message-ID: <47CF7EBF.6000009@freebsd.org> In-Reply-To: <20080306033246.GA47280@zim.MIT.EDU> References: <200803051121.m25BLE03035426@repoman.freebsd.org> <20080305182531.GS68971@server.vk2pj.dyndns.org> <20080306021222.GA46783@zim.MIT.EDU> <47CF5D19.3090100@freebsd.org> <20080306033246.GA47280@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47CF7EBF.6000009>