History log of /seL4-test-master/projects/musllibc/src/math/fma.c
Revision Date Author Comments
# 6e76e154 08-Feb-2015 Szabolcs Nagy <nsz@port70.net>

add parenthesis in fma.c to clarify intent and silence warnings


# 8f438115 07-Oct-2013 Szabolcs Nagy <nsz@port70.net>

math: fix rare underflow issue in fma

the issue is described in commits 1e5eb73545ca6cfe8b918798835aaf6e07af5beb
and ffd8ac2dd50f99c3c83d7d9d845df9874ec3e7d5


# 63b9cc77 04-Sep-2013 Szabolcs Nagy <nsz@port70.net>

math: remove *_WORD64 macros from libm.h

only fma used these macros and the explicit union is clearer


# 34660d73 04-Sep-2013 Szabolcs Nagy <nsz@port70.net>

math: fix remaining old long double code (erfl, fmal, lgammal, scalbnl)

in lgammal don't handle 1 and 2 specially, in fma use the new ldshape
union instead of ld80 one.


# 1e5eb735 19-May-2013 Szabolcs Nagy <nsz@port70.net>

math: add fma TODO comments about the underflow issue

The underflow exception is not raised correctly in some
cornercases (see previous fma commit), added comments
with examples for fmaf, fmal and non-x86 fma.

In fmaf store the result before returning so it has the
correct precision when FLT_EVAL_METHOD!=0


# ffd8ac2d 18-May-2013 Szabolcs Nagy <nsz@port70.net>

math: fix two fma issues (only affects non-nearest rounding mode, x86)

1) in downward rounding fma(1,1,-1) should be -0 but it was 0 with
gcc, the code was correct but gcc does not support FENV_ACCESS ON
so it used common subexpression elimination where it shouldn't have.
now volatile memory access is used as a barrier after fesetround.

2) in directed rounding modes there is no double rounding issue
so the complicated adjustments done for nearest rounding mode are
not needed. the only exception to this rule is raising the underflow
flag: assume "small" is an exactly representible subnormal value in
double precision and "verysmall" is a much smaller value so that
(long double)(small plus verysmall) == small
then
(double)(small plus verysmall)
raises underflow because the result is an inexact subnormal, but
(double)(long double)(small plus verysmall)
does not because small is not a subnormal in long double precision
and it is exact in double precision.
now this problem is fixed by checking inexact using fenv when the
result is subnormal


# 033a9d6a 13-Nov-2012 Szabolcs Nagy <nsz@port70.net>

math: use '#pragma STDC FENV_ACCESS ON' when fenv is accessed


# e5fb6820 20-Jun-2012 nsz <nsz@port70.net>

math: fix fma bug on x86 (found by Bruno Haible with gnulib)

The long double adjustment was wrong:
The usual check is
mant_bits & 0x7ff == 0x400
before doing a mant_bits++ or mant_bits-- adjustment since
this is the only case when rounding an inexact ld80 into
double can go wrong. (only in nearest rounding mode)

After such a check the ++ and -- is ok (the mantissa will end
in 0x401 or 0x3ff).

fma is a bit different (we need to add 3 numbers with correct
rounding: hi_xy + lo_xy + z so we should survive two roundings
at different places without precision loss)

The adjustment in fma only checks for zero low bits
mant_bits & 0x3ff == 0
this way the adjusted value is correct when rounded to
double or *less* precision.
(this is an important piece in the fma puzzle)

Unfortunately in this case the -- is not a correct adjustment
because mant_bits might underflow so further checks are needed
and this was the source of the bug.


# 2786c7d2 19-Mar-2012 nsz <nsz@port70.net>

use scalbn or *2.0 instead of ldexp, fix fmal

Some code assumed ldexp(x, 1) is faster than 2.0*x,
but ldexp is a wrapper around scalbn which uses
multiplications inside, so this optimization is
wrong.

This commit also fixes fmal which accidentally
used ldexp instead of ldexpl loosing precision.

There are various additional changes from the
work-in-progress const cleanups.


# 682e4714 18-Mar-2012 nsz <nsz@port70.net>

remove unnecessary TODO comments from fma.c


# b1cbd707 18-Mar-2012 nsz <nsz@port70.net>

add fma implementation for x86

correctly rounded double precision fma using extended
precision arithmetics for ld80 systems (x87)


# 2e77dc13 16-Mar-2012 Rich Felker <dalias@aerifal.cx>

make fma and lrint functions build without full fenv support

this is necessary to support archs where fenv is incomplete or
unavailable (presently arm). fma, fmal, and the lrint family should
work perfectly fine with this change; fmaf is slightly broken with
respect to rounding as it depends on non-default rounding modes to do
its work.


# b69f695a 12-Mar-2012 Rich Felker <dalias@aerifal.cx>

first commit of the new libm!

thanks to the hard work of Szabolcs Nagy (nsz), identifying the best
(from correctness and license standpoint) implementations from freebsd
and openbsd and cleaning them up! musl should now fully support c99
float and long double math functions, and has near-complete complex
math support. tgmath should also work (fully on gcc-compatible
compilers, and mostly on any c99 compiler).

based largely on commit 0376d44a890fea261506f1fc63833e7a686dca19 from
nsz's libm git repo, with some additions (dummy versions of a few
missing long double complex functions, etc.) by me.

various cleanups still need to be made, including re-adding (if
they're correct) some asm functions that were dropped.