From owner-cvs-all@FreeBSD.ORG Thu Mar 6 05:18:39 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 96C9E1065674 for ; Thu, 6 Mar 2008 05:18:39 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd4mo1so.prod.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6F0BC8FC23 for ; Thu, 6 Mar 2008 05:18:39 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd2mr5so.prod.shaw.ca (pd2mr5so-qfe3.prod.shaw.ca [10.0.141.8]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JXA001RUMQX0JA0@l-daemon> for cvs-all@FreeBSD.ORG; Wed, 05 Mar 2008 22:18:33 -0700 (MST) Received: from pn2ml9so.prod.shaw.ca ([10.0.121.7]) by pd2mr5so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JXA001C0MQXLJ40@pd2mr5so.prod.shaw.ca> for cvs-all@FreeBSD.ORG; Wed, 05 Mar 2008 22:18:33 -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 <0JXA00EO5MQVGY30@l-daemon> for cvs-all@FreeBSD.ORG; Wed, 05 Mar 2008 22:18:32 -0700 (MST) Received: (qmail 1782 invoked from network); Thu, 06 Mar 2008 05:18:31 +0000 Received: from unknown (HELO hexahedron.daemonology.net) (127.0.0.1) by localhost with SMTP; Thu, 06 Mar 2008 05:18:31 +0000 Date: Wed, 05 Mar 2008 21:18:30 -0800 From: Colin Percival In-reply-to: <20080306033807.GB47280@zim.MIT.EDU> To: Colin Percival , Bruce Evans , Bruce Evans , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG Message-id: <47CF7EA6.90802@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> <47CE8396.6020803@freebsd.org> <20080306095645.V7605@delplex.bde.org> <47CF5AE8.2090101@freebsd.org> <20080306033807.GB47280@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:39 -0000 David Schultz wrote: > If gcc actually implemented IEEE 754R / C99 / LIA1 correctly, then > when compiling something like 'double x = y' would require it to > store the value to memory and then reload it to force it to 53-bit > precision. Even this wouldn't work, since it would result in double rounding. > The whole point of double_t is to allow the programmer > to ask for a variable that is "at least double precision", so that > the compiler isn't forced to clip everything to double precision > if it's inefficient to do so. Right -- and that's why numerical analysts should use double (after proving that their code will produce the correct results using double-precision arithmetic) while people who don't understand floating-point math should always use double_t. > However, gcc doesn't compile the above > expression correctly, and FreeBSD works around the problem by > setting the default rounding mode to 53 bits, which is why it's > pointless to increase the size of double_t. I disagee with your characterization of setting the rounding mode as a "workaround", but your conclusion is correct: At the moment, increasing the size of double_t is pointless. Colin Percival