cvs commit: src/sys/i386/include _types.h

[Colin Percival]

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