From owner-cvs-all@FreeBSD.ORG Thu Mar 6 05:30:15 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 0F4B4106566B for ; Thu, 6 Mar 2008 05:30:15 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd2mo2so.prod.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id DD1EE8FC23 for ; Thu, 6 Mar 2008 05:30:14 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd3mr5so.prod.shaw.ca (pd3mr5so-qfe3.prod.shaw.ca [10.0.141.12]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JXA009QDNADHC6Z@l-daemon> for cvs-all@FreeBSD.org; Wed, 05 Mar 2008 22:30:13 -0700 (MST) Received: from pn2ml10so.prod.shaw.ca ([10.0.121.80]) by pd3mr5so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JXA00KMDNAB4L70@pd3mr5so.prod.shaw.ca> for cvs-all@FreeBSD.org; Wed, 05 Mar 2008 22:30:12 -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 <0JXA007HYNAAOC30@l-daemon> for cvs-all@FreeBSD.org; Wed, 05 Mar 2008 22:30:11 -0700 (MST) Received: (qmail 1820 invoked from network); Thu, 06 Mar 2008 05:30:09 +0000 Received: from unknown (HELO hexahedron.daemonology.net) (127.0.0.1) by localhost with SMTP; Thu, 06 Mar 2008 05:30:09 +0000 Date: Wed, 05 Mar 2008 21:30:09 -0800 From: Colin Percival In-reply-to: <20080305230954.X55190@odysseus.silby.com> To: Mike Silbersack Message-id: <47CF8161.1060202@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> <20080305230954.X55190@odysseus.silby.com> User-Agent: Thunderbird 2.0.0.9 (X11/20071117) Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans , cvs-all@FreeBSD.org 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:30:15 -0000 Mike Silbersack wrote: > On Wed, 5 Mar 2008, Bruce Evans wrote: >> Change float_t and double_t to long double on i386. All floating point > > 1) Does this really change every double to a long double in anything > compiled? No, it changes double_t (which is not the same as double). > 2) How does this affect ABI compatibility? This breaks ABI compatibility (when people use float_t or double_t). > 3) How does this change the operation of various programs in the ports > tree that use floating point, such as mplayer, mpg123, etc. Will this > cause different behavior when these apps are used on FreeBSD vs other > operating systems? Most code in the ports tree will be using double instead of double_t, and will consequently not be affected. Code which uses double_t will be slower due to the increased cost of loads and stores, and may produce different output if it changes the i387 precision flags. At the moment, FreeBSD behaves the same way as Microsoft Windows and C99, and differently from Linux: Linux sets the i387 by default to extended precision, which has the result of decreasing the average rounding error while increasing the maximum rounding error (due to double rounding when values which were internally rounded to extended precision are rounded to double precision later) and sometimes breaking code entirely (when the properties of floating-point rounding are used deliberately, e.g., to rapidly round a floating-point value to the nearest integer). I've answered queries from some mathematicians and scientists who were confused as to why they were seeing higher rounding errors on FreeBSD and Windows than they were on Linux; but when I've explained the behavioural differences to numerical analysts, the universal reaction I've received has been "dear god, Linux does WHAT?" -- oddly enough, mathematicians like to think that proving that their code is correct will be enough to ensure that it will produce correct output. Colin Percival