ISNAN bug in gfortran 4.3?

Tobias Burnus burnus@net-b.de
Fri Apr 24 20:09:00 GMT 2009


Matt,

Matt Fago wrote:
> I have a large (unfortunately proprietary) F95/C code that was experiencing
> some obvious memory corruption (verified by valgrind) that was fixed by 
> commenting out a few calls in a loop to ISNAN of the form:
>    
>    DOUBLE PRECISION K(200)
>    INTEGER I
>    IF (ISNAN(K(I))) THEN   ! always false with test case
>
> I did see that ISNAN is documented as taking REALs, but converting using 
> REAL() did not fix the issue (nor did using REAL temporaries).
>   

I'm not aware of any problem with the NaN check. The standard C check
whether a variable x is NaN is to do  "if (x != x)"  (in Fortran "if(x
/= x)" work as well). If I look at the dump (-fdump-tree-original) using
gfortran 4.3 and gfortran 4.4, it looks ok:

  if (SAVE_EXPR <k[(integer(kind=8)) i + -1]> unord SAVE_EXPR
<k[(integer(kind=8)) i + -1]>)

Thus I assume that the NaN part works. Did you compile with
"-ffast-math"? I'm asking because -ffast-math implies -ffinite-math-only
which can then transform "if(x != x)" (or "if(isnan(x))" in Fortran
syntax) into "if(false)" (or "if(.false.)") and then remove the whole if
block. -- That would explain why it does not work (assuming it doesn't).
The other question is why commenting out ISNAN helps with the memory
corruption - I think there should be no reason for that, except of (bad)
luck which hides another problem.

Tobias



More information about the Fortran mailing list