Date: Wed, 05 Mar 2008 21:30:09 -0800 From: Colin Percival <cperciva@freebsd.org> To: Mike Silbersack <silby@silby.com> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <bde@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/include _types.h Message-ID: <47CF8161.1060202@freebsd.org> In-Reply-To: <20080305230954.X55190@odysseus.silby.com> References: <200803051121.m25BLE03035426@repoman.freebsd.org> <20080305230954.X55190@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47CF8161.1060202>