This wasn't a compiler bug; mpfr_pow is really buggy.

Added some asserts to show that.


git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@2265 280ebfd0-de03-0410-8827-d642c229c3f4

2 files changed, 6 insertions, 0 deletions

diff --git a/BUGS b/BUGS
index 5975b8be4..b2271fbb5 100644
--- a/BUGS
+++ b/BUGS
@@ -57,3 +57,5 @@ Potential bugs:
 
 * mpfr_hypot may fail for x very large, y very small and a very large
   target precision.
+
+* mpfr_pow fails on (1, 0.5).
diff --git a/pow.c b/pow.c
index db9b59595..9a0ae7e4c 100644
--- a/pow.c
+++ b/pow.c
@@ -319,6 +319,10 @@ mpfr_pow (mpfr_ptr z, mpfr_srcptr x, mpfr_srcptr y, mp_rnd_t rnd_mode)
         mpfr_mul (te, y, ti, GMP_RNDU);       /* y*ln(n) */
         mpfr_exp (t, te, GMP_RNDN);         /* exp(x*ln(n))*/
 
+        MPFR_ASSERTN(MPFR_IS_FP(te));
+        MPFR_ASSERTN(MPFR_NOTZERO(te));
+        /* otherwise MPFR_EXP(te) below doesn't exist */
+
 	/* estimate of the error -- see pow function in algorithms.ps */
         err = Nt - (MPFR_EXP(te) + 3);