mod function sometimes returns NaN

mod function sometimes returns NaN

My program has four subroutines that call MOD one or more times. I'm finding that the various MOD calls in the program will sometimes return NaN. Any ideas on how I could track if this is some problem on my end?

I am only experiencing this on the 64bit platform (10.1.021). The 32bit build works without any problem.


If I replace the MOD call with


I do not get a NaN result.

I wrote out all the values used in the above MOD calculation to a file and wrote a simple program to read in the values and do a MOD on them. This simple program does not exhibit any problem with the MOD call.

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Is function RESULT declared as DOUBLE PRECISION everywhere it is used?

Retired 12/31/2016

yes, RESULT is declared as DOUBLE PRECISION in all instances

At this point I would ask that you submit a test case, if you can, to Intel Premier Support. Before doing that you might want to try it with 10.1.024.

Retired 12/31/2016

I tracked down an interesting occurrence of NaN related to MOD use in Fortran in a mixed-language application. It this case fmod was resolved from Microsofts msvcr80.dll instead of from Intels libm. The NaN only occurs on Intel 64 and relates to Microsofts fmod reacting to a pre-existing denormal (DE); it was not reproducible on IA-32.

Check if fmod is resolved from msvcr80.dll. If so then re-arrange the link accordingly so the appropriate libm is linked ahead of msvcr80.dll and see if that stops the production of the NaN.

Yes! This is exactly my scenario - mixed language program, happens only on the 64bit build. The main program is written in C++, so I was using MSVC to link the whole thing. I modified the link line so that libmmd.lib was found first and the problem is gone.


Some more questions for more experienced users...

How do you go about determining the correct order of linking in a mixed language situation? In a situation like this, it appears the symbol name exists in both a Fortran library and a C library. Which one should get linked first? What happens to invocations of that function in the "other" language?

In this case, I did not explicitly specify linking against libmmd.lib. I suppose the C++ compiler by default linked msvcr80.lib to resolve the "mod". The result then was that the Fortran code called the C "mod", not the Fortran "mod", and generated these NaNs. I suppose calling "mod" from the C side in this instance would have been fine.

How about the reverse situation that I have now created. I am explicitly putting libmmd.lib into the link line before other libraries. Now the Fortran code is getting the Fortran "mod" function and the NaN results are gone. What about the C side though? Will this now cause a problem if I have a "mod" call on the C side?

It's rare that this is an issue. If I understand Kevin's note correctly, the MS implementation has a bug, or at least an undesirable (I'd think) feature. Generally, you want to make sure that all references are satisfied by libraries found later in the list, though you don't have explicit control over the list since "default library directives" in the object code determine most of which libraries will be used. It's only in the case of a problem or conflict that you may need to force one library to be seen earlier.

If you want to see the order the linker uses, turn on /verbose in the linker options ("Show progress messages"). It can be very illuminating.

Retired 12/31/2016

To answer your other question, since libmmd and msvcrt both provide "mod" routines with the same external name and same interface, if you have libmmd first then your C code will use libmmd's version and msvcrt's version will not be used since that name has already been resolved by libmmd.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today