Cubing positive real(8) leads to NaN

[kschmitt_dom]

Imagine the following FORTRAN code Parallel Studio XE 2011 (with default real(8) but most other relevant compiler options unchanged from their default):

__________________________________

program example1

real x,t,a,b,c

a=1.; b=1.; c=1.
t=0.00635
x=kyle(t,a,b,c)

end

function kyle(t,a,b,c)

real kyle,t,a,b,c

kyle=t**3.0

end

___________________________________

For some combinations of parameters a,b,c the function behaves correctly. For others, the function evaluates t to be NaN. Is there any clear explanation of why this might be?

Obviously, there is more going on in my code but I've extracted what I think to be relative charateristics. If there is no answer to my question above, I will add more details.

Thank you.

[Steven_L_Intel1]

I think you are going to have to determine which actual values create the problem and show us a program that demonstrates it.

[IanH · Accepted solution]

Note that you haven't declared the type of the function in the main program. Implicit typing rules would result in a mismatch, which could result in lots of interesting things happening. Consider using IMPLICIT NONE in all program units and putting the function in a module.

[TimP]

zero or negative t is likely to produce NaN when raised to 3.0 power, where 3 (integer) power is OK.

[kschmitt_dom]

The program is far more complex and (as is so often the case I am sure) proprietary. I would make an attempt to recreate the error in a streamlined program, but it appears that it was in fact due to implicit typing as suggesting by IanH.

Other details: My variable "t" in the actual program is an *intermediate* variable used inside the function "kyle", so it seems weird that there would be a implicit typing mismatch just because the function return "kyle" was not explicitly typed in the main program. Furthermore, if I debug stop immediately before returning from "kyle", my debugger shows "t" to be 3.65D-02 but shows "kyle" to be NaN.

Nonetheless, expliciting assigning "kyle" to real in the main program appears to have fixed my problem.

Thank you!

[Steven_L_Intel1]

If you are building in Visual Studio, make sure that Warnings > Generated Interface Checking is enabled. This is on by default for new projects and can catch errors of this nature. From the command line, specify /warn:interface

[mecej4]

> so it seems weird that there would be a implicit typing mismatch just because the function return "kyle" was not explicitly typed in the main program

Unlike in, say, C, in Fortran all type declarations have program-unit-scope, not file-scope.

Some compilers, egged on by a proper choice of diagnostic options, may warn you of the type mismatch at compile time or catch the mismatch at run-time. However, the source code needs to be rectified.

The short example that you provided will not work to exhibit the problem since, in the main program, the result of the function call is not used and the compiler can optimize out the function call entirely.

On X86 CPUs, the convention is that integer functions return the result in register EAX, whereas real/double-precision functions return the result in ST0. With the mismatch that you had, the function puts the result into ST0, but the caller takes the content of EAX as the result.

[TimP]

I took the original description as implying that -real-size:64 (or equivalent) is in effect for the entire build. Needless to say, making the type explicit in the source code, and allowing compiler to check interfaces, may avoid mistakes.

[mecej4]

I don't see why choosing the -real-size:64 option would have any effect on the compiled code from a reference to a variable or function that is implicitly typed to be INTEGER.

[TimP]

Yes, declaring a real function result as implicit integer appears to be an outright bug in the example code, such that no meaningful result may be expected. On the other hand, there is no NaN representation in integer types. Nor would the common expectation from x87 code that a real function result of any type could be received as any other real type work, as in that case any real function return type would be ignored when receiving an integer.