From owner-cvs-src@FreeBSD.ORG Thu Mar 6 03:31:35 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C5F9106566B; Thu, 6 Mar 2008 03:31:35 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 833408FC1B; Thu, 6 Mar 2008 03:31:34 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.2/8.14.2) with ESMTP id m263Wku5047399; Wed, 5 Mar 2008 22:32:46 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m263Wkxp047398; Wed, 5 Mar 2008 22:32:46 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Wed, 5 Mar 2008 22:32:46 -0500 From: David Schultz To: Colin Percival Message-ID: <20080306033246.GA47280@zim.MIT.EDU> Mail-Followup-To: Colin Percival , Peter Jeremy , Bruce Evans , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200803051121.m25BLE03035426@repoman.freebsd.org> <20080305182531.GS68971@server.vk2pj.dyndns.org> <20080306021222.GA46783@zim.MIT.EDU> <47CF5D19.3090100@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47CF5D19.3090100@freebsd.org> Cc: Peter Jeremy , src-committers@FreeBSD.ORG, Bruce Evans , cvs-all@FreeBSD.ORG, cvs-src@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/include _types.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 03:31:35 -0000 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.