<feed xmlns='http://www.w3.org/2005/Atom'>
<title>musl/src/math, branch v1.1.18</title>
<subtitle>musl - an implementation of the standard library for Linux-based systems</subtitle>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/'/>
<entry>
<title>math: rewrite fma with mostly int arithmetics</title>
<updated>2017-10-14T02:30:45+00:00</updated>
<author>
<name>Szabolcs Nagy</name>
<email>nsz@port70.net</email>
</author>
<published>2017-09-17T17:31:20+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=907476925fca05f24ebca5fcdc21f1e58ba7b313'/>
<id>907476925fca05f24ebca5fcdc21f1e58ba7b313</id>
<content type='text'>
the freebsd fma code failed to raise underflow exception in some
cases in nearest rounding mode (affects fmal too) e.g.

  fma(-0x1p-1000, 0x1.000001p-74, 0x1p-1022)

and the inexact exception may be raised spuriously since the fenv
is not saved/restored around the exact multiplication algorithm
(affects x86 fma too).

another issue is that the underflow behaviour when the rounded result
is the minimal normal number is target dependent, ieee754 allows two
ways to raise underflow for inexact results: raise if the result before
rounding is in the subnormal range (e.g. aarch64, arm, powerpc) or if
the result after rounding with infinite exponent range is in the
subnormal range (e.g. x86, mips, sh).

to avoid all these issues the algorithm was rewritten with mostly int
arithmetics and float arithmetics is only used to get correct rounding
and raise exceptions according to the behaviour of the target without
any fenv.h dependency. it also unifies x86 and non-x86 fma.

fmaf is not affected, fmal need to be fixed too.

this algorithm depends on a_clz_64 and it required a few spurious
instructions to make sure underflow exception is raised in a particular
corner case. (normally FORCE_EVAL(tiny*tiny) would be used for this,
but on i386 gcc is broken if the expression is constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57245
and there is no easy portable fix for the macro.)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
the freebsd fma code failed to raise underflow exception in some
cases in nearest rounding mode (affects fmal too) e.g.

  fma(-0x1p-1000, 0x1.000001p-74, 0x1p-1022)

and the inexact exception may be raised spuriously since the fenv
is not saved/restored around the exact multiplication algorithm
(affects x86 fma too).

another issue is that the underflow behaviour when the rounded result
is the minimal normal number is target dependent, ieee754 allows two
ways to raise underflow for inexact results: raise if the result before
rounding is in the subnormal range (e.g. aarch64, arm, powerpc) or if
the result after rounding with infinite exponent range is in the
subnormal range (e.g. x86, mips, sh).

to avoid all these issues the algorithm was rewritten with mostly int
arithmetics and float arithmetics is only used to get correct rounding
and raise exceptions according to the behaviour of the target without
any fenv.h dependency. it also unifies x86 and non-x86 fma.

fmaf is not affected, fmal need to be fixed too.

this algorithm depends on a_clz_64 and it required a few spurious
instructions to make sure underflow exception is raised in a particular
corner case. (normally FORCE_EVAL(tiny*tiny) would be used for this,
but on i386 gcc is broken if the expression is constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57245
and there is no easy portable fix for the macro.)
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc64: add single-instruction math functions</title>
<updated>2017-06-23T20:01:00+00:00</updated>
<author>
<name>Rich Felker</name>
<email>dalias@aerifal.cx</email>
</author>
<published>2017-06-23T20:01:00+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=94f744195e17cf787a36c259254d56386b31fe20'/>
<id>94f744195e17cf787a36c259254d56386b31fe20</id>
<content type='text'>
while the official elfv2 abi for "powerpc64le" sets power8 as the
baseline isa, we use it for both little and big endian powerpc64
targets and need to maintain compatibility with pre-power8 models. the
instructions for sqrt, fabs, and fma are in the baseline isa; support
for the rest is conditional via predefined isa-level macros.

patch by David Edelsohn.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
while the official elfv2 abi for "powerpc64le" sets power8 as the
baseline isa, we use it for both little and big endian powerpc64
targets and need to maintain compatibility with pre-power8 models. the
instructions for sqrt, fabs, and fma are in the baseline isa; support
for the rest is conditional via predefined isa-level macros.

patch by David Edelsohn.
</pre>
</div>
</content>
</entry>
<entry>
<title>s390x: add single-instruction math functions</title>
<updated>2017-06-23T19:28:10+00:00</updated>
<author>
<name>Rich Felker</name>
<email>dalias@aerifal.cx</email>
</author>
<published>2017-06-23T19:28:10+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=ce385fcfb2db74b109067083db4a26ca810eaa14'/>
<id>ce385fcfb2db74b109067083db4a26ca810eaa14</id>
<content type='text'>
these were introduced in z196 and not available in the baseline (z900)
ISA level. use __HTM__ as an alternate indicator for ISA level, since
gcc did not define __ARCH__ until 7.x.

patch by David Edelsohn.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
these were introduced in z196 and not available in the baseline (z900)
ISA level. use __HTM__ as an alternate indicator for ISA level, since
gcc did not define __ARCH__ until 7.x.

patch by David Edelsohn.
</pre>
</div>
</content>
</entry>
<entry>
<title>fix scalbn when result is in the subnormal range</title>
<updated>2017-04-21T21:31:00+00:00</updated>
<author>
<name>Szabolcs Nagy</name>
<email>nsz@port70.net</email>
</author>
<published>2017-04-03T00:38:13+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=8c44a060243f04283ca68dad199aab90336141db'/>
<id>8c44a060243f04283ca68dad199aab90336141db</id>
<content type='text'>
in nearest rounding mode scalbn could introduce double rounding error
when an intermediate value and the final result were both in the
subnormal range e.g.

  scalbn(0x1.7ffffffffffffp-1, -1073)

returned 0x1p-1073 instead of 0x1p-1074, because the intermediate
computation got rounded to 0x1.8p-1023.

with the fix an intermediate value can only be in the subnormal range
if the final result is 0 which is correct even after double rounding.
(there still can be two roundings so signals may be raised twice, but
that's only observable with trapping exceptions which is not supported.)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
in nearest rounding mode scalbn could introduce double rounding error
when an intermediate value and the final result were both in the
subnormal range e.g.

  scalbn(0x1.7ffffffffffffp-1, -1073)

returned 0x1p-1073 instead of 0x1p-1074, because the intermediate
computation got rounded to 0x1.8p-1023.

with the fix an intermediate value can only be in the subnormal range
if the final result is 0 which is correct even after double rounding.
(there still can be two roundings so signals may be raised twice, but
that's only observable with trapping exceptions which is not supported.)
</pre>
</div>
</content>
</entry>
<entry>
<title>aarch64: add single instruction math functions</title>
<updated>2017-03-21T16:39:18+00:00</updated>
<author>
<name>Szabolcs Nagy</name>
<email>nsz@port70.net</email>
</author>
<published>2017-03-19T04:26:45+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=54807d47acecab778498ced88ce8f62bfa16e379'/>
<id>54807d47acecab778498ced88ce8f62bfa16e379</id>
<content type='text'>
this should increase performance and reduce code size on aarch64.

the compiled code was checked against using __builtin_* instead
of inline asm with gcc-6.2.0.

lrint is two instructions.

c with inline asm is used because it is safer than a pure asm
implementation, this prevents ll{rint,round} to be an alias
of l{rint,round} (because the types don't match) and depends
on gcc style inline asm support.

ceil, floor, round, trunc can either raise inexact on finite
non-integer inputs or not raise any exceptions. the new
implementation does not raise exceptions while the generic
c code does.

on aarch64, the underflow exception is signaled before rounding
(ieee 754 allows both before and after rounding, but it must be
consistent), the generic fma c code signals it after rounding
so using single instruction fixes a slight conformance issue too.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
this should increase performance and reduce code size on aarch64.

the compiled code was checked against using __builtin_* instead
of inline asm with gcc-6.2.0.

lrint is two instructions.

c with inline asm is used because it is safer than a pure asm
implementation, this prevents ll{rint,round} to be an alias
of l{rint,round} (because the types don't match) and depends
on gcc style inline asm support.

ceil, floor, round, trunc can either raise inexact on finite
non-integer inputs or not raise any exceptions. the new
implementation does not raise exceptions while the generic
c code does.

on aarch64, the underflow exception is signaled before rounding
(ieee 754 allows both before and after rounding, but it must be
consistent), the generic fma c code signals it after rounding
so using single instruction fixes a slight conformance issue too.
</pre>
</div>
</content>
</entry>
<entry>
<title>fix threshold constants in j0f, y0f, j1f, y1f</title>
<updated>2017-03-15T04:15:28+00:00</updated>
<author>
<name>Szabolcs Nagy</name>
<email>nsz@port70.net</email>
</author>
<published>2017-03-15T01:55:49+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=8cba1dc46c8f29261aa441e70bac798f2c2c0f58'/>
<id>8cba1dc46c8f29261aa441e70bac798f2c2c0f58</id>
<content type='text'>
partly following freebsd rev 279491
https://svnweb.freebsd.org/base?view=revision&amp;revision=279491
(musl had some of the fixes before freebsd).

the change should not matter much for j0f, y0f, but it improves
j1f and y1f in [2.5,~3.75] (that is [0x40200000,~0x40700000]).
near roots (e.g. around 3.8317 for j1f) there are still large
ulp errors.

dropped code that tried to raise inexact.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
partly following freebsd rev 279491
https://svnweb.freebsd.org/base?view=revision&amp;revision=279491
(musl had some of the fixes before freebsd).

the change should not matter much for j0f, y0f, but it improves
j1f and y1f in [2.5,~3.75] (that is [0x40200000,~0x40700000]).
near roots (e.g. around 3.8317 for j1f) there are still large
ulp errors.

dropped code that tried to raise inexact.
</pre>
</div>
</content>
</entry>
<entry>
<title>math: fix pow signed shift ub</title>
<updated>2016-10-20T05:32:27+00:00</updated>
<author>
<name>Szabolcs Nagy</name>
<email>nsz@port70.net</email>
</author>
<published>2016-10-04T01:58:56+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=688d3da0f1730daddbc954bbc2d27cc96ceee04c'/>
<id>688d3da0f1730daddbc954bbc2d27cc96ceee04c</id>
<content type='text'>
j is int32_t and thus j&lt;&lt;31 is undefined if j==1, so j is changed to
uint32_t locally as a quick fix, the generated code is not affected.

(this is a strict conformance fix, future c standard may allow 1&lt;&lt;31,
see DR 463.  the bug was inherited from freebsd fdlibm, the proper fix
is to use uint32_t for all bit hacks, but that requires more intrusive
changes.)

reported by Daniel Sabogal
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
j is int32_t and thus j&lt;&lt;31 is undefined if j==1, so j is changed to
uint32_t locally as a quick fix, the generated code is not affected.

(this is a strict conformance fix, future c standard may allow 1&lt;&lt;31,
see DR 463.  the bug was inherited from freebsd fdlibm, the proper fix
is to use uint32_t for all bit hacks, but that requires more intrusive
changes.)

reported by Daniel Sabogal
</pre>
</div>
</content>
</entry>
<entry>
<title>math: fix 128bit long double inverse trigonometric functions</title>
<updated>2016-08-30T20:00:38+00:00</updated>
<author>
<name>Szabolcs Nagy</name>
<email>nsz@port70.net</email>
</author>
<published>2016-08-23T19:47:53+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=5b5db97f7e80bde2678aed72336a28375e800354'/>
<id>5b5db97f7e80bde2678aed72336a28375e800354</id>
<content type='text'>
there was a copy paste error that could cause large ulp errors
in atan2l, atanl, asinl and acosl on aarch64, mips64 and mipsn32.

(the implementation is from freebsd fdlibm, but the tail end
of the polynomial was wrong. 128 bit long double functions
are not yet tested so this went undetected.)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
there was a copy paste error that could cause large ulp errors
in atan2l, atanl, asinl and acosl on aarch64, mips64 and mipsn32.

(the implementation is from freebsd fdlibm, but the tail end
of the polynomial was wrong. 128 bit long double functions
are not yet tested so this went undetected.)
</pre>
</div>
</content>
</entry>
<entry>
<title>math: fix expf(-NAN) and exp2f(-NAN) to return -NAN instead of 0</title>
<updated>2016-03-04T22:58:49+00:00</updated>
<author>
<name>Szabolcs Nagy</name>
<email>nsz@port70.net</email>
</author>
<published>2016-03-04T21:23:33+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=b023c03b574acdfd73418314a5dcaa83e5cea5a0'/>
<id>b023c03b574acdfd73418314a5dcaa83e5cea5a0</id>
<content type='text'>
expf(-NAN) was treated as expf(-large) which unconditionally
returns +0, so special case +-NAN.
reported by Petr Hosek.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
expf(-NAN) was treated as expf(-large) which unconditionally
returns +0, so special case +-NAN.
reported by Petr Hosek.
</pre>
</div>
</content>
</entry>
<entry>
<title>work around regression building for armhf with clang (compiler bug)</title>
<updated>2016-02-19T01:20:07+00:00</updated>
<author>
<name>Rich Felker</name>
<email>dalias@aerifal.cx</email>
</author>
<published>2016-02-19T01:20:07+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=71c334f951d9ffa4d8bdc71bdd49628e5ae4512b'/>
<id>71c334f951d9ffa4d8bdc71bdd49628e5ae4512b</id>
<content type='text'>
commit e4355bd6bec89688e8c739cd7b4c76e675643dca moved the math asm
from external source files to inline asm, but unfortunately, all
current releases of clang use the wrong inline asm constraint codes
for float and double ("w" and "P" instead of "t" and "w",
respectively). this patch adds detection for the bug in configure,
and, for now, just disables the affected asm on broken clang versions.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e4355bd6bec89688e8c739cd7b4c76e675643dca moved the math asm
from external source files to inline asm, but unfortunately, all
current releases of clang use the wrong inline asm constraint codes
for float and double ("w" and "P" instead of "t" and "w",
respectively). this patch adds detection for the bug in configure,
and, for now, just disables the affected asm on broken clang versions.
</pre>
</div>
</content>
</entry>
</feed>
