| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
