Fortran pow (complex ** huge) returns NaN instead of Inf ?

Kaveh R. Ghazi ghazi@caip.rutgers.edu
Thu Jun 25 18:29:00 GMT 2009


From: "Steve Kargl" <sgk@troutmask.apl.washington.edu>

> troutmask:sgk[225] gfc4x -o z -fno-range-check c.f90
> troutmask:sgk[226] ./z
> (      -Infinity,      +Infinity)
> (  2.0000000    , -4.3000002    )
>  3.40282347E+38
> (            NaN,            NaN)

Ah I didn't know about -fno-range-check.  FWIW, MPC passed these inputs also 
yields (-Inf, Inf) at precision 24 for float.  So it won't be changing 
gfortran's behavior for this case of pow (foo ** real4).

The difference that remains is my original example which is in the pow (foo 
** int) handler in the fortran.  I believe the frontend code to compute this 
has a bug and yields NaN incorrectly.  Using MPC there fixes it, but breaks 
the testcase because it incorporates the buggy value in its test.

So the options I see for using mpc_pow are:

1.  Fix the testcase and live with the testcase failing for people who don't 
use MPC > 0.6 (which has mpc_pow).

2.  Leave the testcase as-is until the MPC hard-requirement switchover.  It 
will fail for anyone who uses MPC > 0.6.

3.  Comment out the offending lines in the testcase, put them back in after 
the hard-requirement switch.  Nobody will see extra failures in this case. 
(I'll add that to PR40302's todo list.)

4.  Fix the testcase, and fix arith.c:complex_pow() so that it doesn't get a 
NaN.  It's probably the "right" solution, but I don't volunteer to fix the 
old code. :-)

        Other ideas?
        --Kaveh



More information about the Fortran mailing list