From owner-cvs-all@FreeBSD.ORG Thu Mar 6 05:18:59 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 157C21065671 for ; Thu, 6 Mar 2008 05:18:59 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd3mo3so.prod.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id E0FF28FC14 for ; Thu, 6 Mar 2008 05:18:58 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd4mr4so.prod.shaw.ca (pd4mr4so-qfe3.prod.shaw.ca [10.0.141.215]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JXA00EVTMRM5E20@l-daemon> for cvs-all@FreeBSD.ORG; Wed, 05 Mar 2008 22:18:58 -0700 (MST) Received: from pn2ml8so.prod.shaw.ca ([10.0.121.152]) by pd4mr4so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JXA00B4YMRLQN80@pd4mr4so.prod.shaw.ca> for cvs-all@FreeBSD.ORG; Wed, 05 Mar 2008 22:18:58 -0700 (MST) Received: from hexahedron.daemonology.net ([24.80.10.198]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with SMTP id <0JXA00LLFMRK8D60@l-daemon> for cvs-all@FreeBSD.ORG; Wed, 05 Mar 2008 22:18:57 -0700 (MST) Received: (qmail 1790 invoked from network); Thu, 06 Mar 2008 05:18:55 +0000 Received: from unknown (HELO hexahedron.daemonology.net) (127.0.0.1) by localhost with SMTP; Thu, 06 Mar 2008 05:18:55 +0000 Date: Wed, 05 Mar 2008 21:18:55 -0800 From: Colin Percival In-reply-to: <20080306033246.GA47280@zim.MIT.EDU> To: Colin Percival , Peter Jeremy , Bruce Evans , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG Message-id: <47CF7EBF.6000009@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Enigmail-Version: 0.95.5 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> User-Agent: Thunderbird 2.0.0.9 (X11/20071117) Cc: Subject: Re: cvs commit: src/sys/i386/include _types.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 05:18:59 -0000 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