This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ISNAN bug in gfortran 4.3?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]