]> git.ipfire.org Git - thirdparty/glibc.git/commit - math/s_ccosh_template.c
Clean up some complex functions raising FE_INVALID.
authorJoseph Myers <joseph@codesourcery.com>
Fri, 14 Oct 2016 00:12:56 +0000 (00:12 +0000)
committerJoseph Myers <joseph@codesourcery.com>
Fri, 14 Oct 2016 00:12:56 +0000 (00:12 +0000)
commite886c36771c1a941cdfc5c4df4dc85b3f8f6d4ef
tree835762fb453807749de2db0f78ef7bdea719a620
parent07c18a008c2ed8f5660adba2b778671db159a141
Clean up some complex functions raising FE_INVALID.

Some of the complex arithmetic functions have the following pattern:
in some piece of code, one part of the input (real or imaginary,
depending on the function) is either infinite or NaN.  Part of the
result is to be set to NaN in either case, and FE_INVALID raised only
if the relevant part of the input was infinite.

In such a case, there is no actual need for the conditional on the
type of the input, since subtracting the relevant part of the input
from itself will produce a NaN, with FE_INVALID only if the relevant
part of the input was infinite.  This simplifies the code, and as a
quality-of-implementation matter also improves things by propagating
NaN payloads.  (Right now these functions always raise FE_INVALID for
signaling NaN arguments because of the call to fpclassify - at least
unless glibc is built with -Os - but if fpclassify moves to using
integer arithmetic in future, doing arithmetic on the NaN argument
also ensures an exception for sNaNs.)

Tested for x86_64 and x86.

* math/s_ccosh_template.c (M_DECL_FUNC (__ccosh)): Instead of
raising FE_INVALID with feraisexcept in case where part of
argument is infinite, subtract that part of argument from itself.
* math/s_cexp_template.c (M_DECL_FUNC (__cexp)): Likewise.
* math/s_csin_template.c (M_DECL_FUNC (__csin)): Likewise.
* math/s_csinh_template.c (M_DECL_FUNC (__csinh)): Likewise.
ChangeLog
math/s_ccosh_template.c
math/s_cexp_template.c
math/s_csin_template.c
math/s_csinh_template.c