about summary refs log tree commit diff
path: root/math/w_pow.c
diff options
context:
space:
mode:
authorJoseph Myers <joseph@codesourcery.com>2016-12-02 22:50:46 +0000
committerJoseph Myers <joseph@codesourcery.com>2016-12-02 22:50:46 +0000
commit72d839a42f4c4ed2e0a5202a0d9829c3debae20f (patch)
treef6fede160ae712f5bcd6dd3990335d47bfcce381 /math/w_pow.c
parent84aa75162cd5ba73caa76864496fadd2551a5caa (diff)
downloadglibc-72d839a42f4c4ed2e0a5202a0d9829c3debae20f.tar.gz
glibc-72d839a42f4c4ed2e0a5202a0d9829c3debae20f.tar.xz
glibc-72d839a42f4c4ed2e0a5202a0d9829c3debae20f.zip
Fix pow (qNaN, 0) result with -lieee (bug 20919), remove dead parts of wrappers.
The dbl-64 implementation of __ieee754_pow returns a NaN for pow
(qNaN, 0) when it should return 1.  Normally this is covered up by the
wrappers ending up calling __kernel_standard which fixes up the result
for this case, but for -lieee the wrappers are bypassed and the bad
result gets through as a return value.

Now, the wrappers fixing this are dealing with variant error handling
that wants a result of NaN for pow (qNaN, 0), and only ever call
__kernel_standard for this case if NaN resulted from __ieee754_pow.
This leads to a question of whether the dbl-64 code might be
deliberately returning NaN in order to use those code paths.  However,
I can find no sign that this is deliberate.  If it were deliberate one
would expect other implementations to do the same, and would expect
the return of NaN to be very old, but it appears it came in by
accident when the present e_pow.c implementation replaced an fdlibm
implementation in 2001.  So it appears to be unintended that this path
through the pow wrapper could be used at all.

So this patch fixes the implementation to return 1 in this case as
expected.  This is consistent with all the other implementations.  The
relevant path through the wrappers is now unreachable, so is removed
(which is the main motivation of this patch: to avoid that path
becoming accidentally reachable when implementing TS 18661-1 semantics
that pow (sNaN, 0) should return qNaN with "invalid" raised).  Another
path that would require __ieee754_pow (0, 0) to return 0 is also
unreachable (as all implementations return 1, in accordance with C99
semantics), so is removed as well.

Note: we don't have anything set up to test -lieee, which in any case
is obsolescent (at some point we should remove the ability for new
programs to access _LIB_VERSION or define matherr and have it called
by glibc).  So testing will be implicit through sNaN tests added when
making sNaN inputs work correctly for pow functions.

Tested for x86_64 and x86.

	[BZ #20919]
	* sysdeps/ieee754/dbl-64/e_pow.c (__ieee754_pow): Do not return
	NaN first argument when raised to power 0.
	* math/w_pow.c (__pow): Do not check for NaN or zero results from
	raising to power zero.
	* math/w_powf.c (__powf): Likewise.
	* math/w_powl.c (__powl): Likewise.
	* sysdeps/ieee754/k_standard.c (__kernel_standard): Do not handle
	pow (0, 0) or pow (NaN, 0).
Diffstat (limited to 'math/w_pow.c')
-rw-r--r--math/w_pow.c24
1 files changed, 5 insertions, 19 deletions
diff --git a/math/w_pow.c b/math/w_pow.c
index 12c0591d34..ed79dbda05 100644
--- a/math/w_pow.c
+++ b/math/w_pow.c
@@ -29,13 +29,7 @@ __pow (double x, double y)
     {
       if (_LIB_VERSION != _IEEE_)
 	{
-	  if (isnan (x))
-	    {
-	      if (y == 0.0)
-		/* pow(NaN,0.0) */
-		return __kernel_standard (x, y, 42);
-	    }
-	  else if (isfinite (x) && isfinite (y))
+	  if (isfinite (x) && isfinite (y))
 	    {
 	      if (isnan (z))
 		/* pow neg**non-int */
@@ -55,19 +49,11 @@ __pow (double x, double y)
 	    }
 	}
     }
-  else if (__builtin_expect (z == 0.0, 0) && isfinite (x) && isfinite (y)
+  else if (__builtin_expect (z == 0.0, 0)
+	   && isfinite (x) && x != 0 && isfinite (y)
 	   && _LIB_VERSION != _IEEE_)
-    {
-      if (x == 0.0)
-	{
-	  if (y == 0.0)
-	    /* pow(0.0,0.0) */
-	    return __kernel_standard (x, y, 20);
-	}
-      else
-	/* pow underflow */
-	return __kernel_standard (x, y, 22);
-    }
+    /* pow underflow */
+    return __kernel_standard (x, y, 22);
 
   return z;
 }