This content has been marked as final. Show 3 replies
Just to clarify, GCC 3.4 only seems to have the NAN arithmetic comparison bug when compiling for 64-bit mode on X86_64 _and_ using an optimization flag (-O, -O2, or -O3).
We did not build ACML with GCC 3.4.
We currently build with GCC 4.1.2 and GCC 4.2.0 (for the OpenMP version), so this issue should not be a problem.
High level languages like Fortran do not necessarily handle comparisons involving NaNs in the way that you suggest, irrespective
of what the IEEE 754 arithmetic standard says. That standard (section 5.7) says that NaNs compare as "unordered" with all other numbers,
including other NaNs. The standard also recommends using a function isnan() to detect whether a value is a NaN. In my experience,
a Fortran comparison involving a NaN can go any which way, and the same comparison written in two parts of the same routine
might go two different ways.
Even if the high level language handled NaNs in the way you would like, I'm not sure it would help much.
LAPACK, BLAS and other routines are not generally designed to expect NaNs. So, however NaN's are handled,
the results you get from a routine call might not be what you expect if you supply input data (e.g. a matrix element) containing a NaN.
You might or might not get a NaN returned in your results.