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