Avoid M_NAN + M_NAN in complex functions.

Some libm complex functions have code that computes M_NAN + M_NAN.
This is nonsensical; it's just equivalent to M_NAN, since it's a quiet
NaN (and the comments suggesting this raises an exception are
similarly wrong).  This patch changes the code just to use M_NAN (and
removes the bogus comments).  (Preferably, code should either
propagate an input NaN or do a computation that raises "invalid" and
generates a default NaN at the same time.  There are various cases,
however, that currently raise "invalid" even for NaN inputs; I think
those are cases where "invalid" is optional in ISO C so a change to
whether it's raised would be OK, but they would still need more
careful consideration than the cases where such issues do not arise.)

Tested for x86_64 and x86 (testsuite, and that installed stripped
shared libraries are unchanged by the patch).

	* math/s_ccosh_template.c (M_DECL_FUNC (__ccosh)): Use M_NAN
	instead of M_NAN + M_NAN.
	* math/s_csinh_template.c (M_DECL_FUNC (__csinh)): Likewise.

1 files changed, 6 insertions, 0 deletions

diff --git a/ChangeLog b/ChangeLog
index 2590895834..ee5f31568c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2016-10-11  Joseph Myers  <joseph@codesourcery.com>
+
+	* math/s_ccosh_template.c (M_DECL_FUNC (__ccosh)): Use M_NAN
+	instead of M_NAN + M_NAN.
+	* math/s_csinh_template.c (M_DECL_FUNC (__csinh)): Likewise.
+
 2016-10-10  Samuel Thibault  <samuel.thibault@ens-lyon.org>
 
 	* misc/getauxval.c [!HAVE_AUX_VECTOR] (__getauxval): Do not define