Behaviour of source different in 2 programs

[François-Xavier]

Dear Intel Forum,

I would first say that i very appreciate reading questions and found a lot of answers to our needs. Thank you all.

I rarely post on forum since a lot of questions are already answers, but this time,... I am really stuck.

This is my problem, explained as clearly as possible:

We use IFORT 11.1.0.65. (we are currently moving to the new version but our industrial release is 11.1.0.65).

We have a routine which is used by two different programs and the behavior is different for the same outputs. This difference is probably due to different compilation/linking options but we were not able to identify such difference.

The portion of code is as follow:

      WNUM  = CMPLX(YC,YD)

In some case YD is very large (higher than 10E+29) and:

1. In the first program a NaN is generated. This the good behavior since it allows us to detect it (using the ISNAN function), print an error message to the user and quit properly the program.
2. In the second program there is a crash with “Multiple floating point traps.” (message generated using the debugger). This crash prevents us to print correct error message.

The routine is compiled using the same options in both programs and the same difference occurs in debug and optim.

     debug = /Z7 /Od /check:all /fpe:0 /Qtrapuv

     optim = /fpe:0 /fltconsistency /Ox

We have tried different values for the /fpe options without impact.

The only known difference is that the main function of the first program (the one generating the NaN) is a C++ function (compiled with VS2008) where for the second program it is a FORTRAN program. Could it explain the different behavior?

What can be done to always generate NaN values and avoid crash?

Thank you so much,

F-Xavier

[TimP]

In the case of Fortran calling Fortran, there is the possibility of in-lining, which you could turn off by /Qip- or by !dir$ NOINLINE

I think legacy usage of CMPLX is not always consistent with standard, so adding the optional kind argument might prevent such inconsistency.

[François-Xavier]

Dear TimP,

Thank you for your answer. We tested your proposal yesterday but, unfortunately did not notice any difference.

Thank you anyway for this tip.

François-Xavier

[jimdempseyatthecove]

The error may be occuring before the CMPLX statement. Have you considered using IEEE_HANDLER to specify an exception handler? This might help diagnose the root cause. By the way, what are the types of WNUM YC, YD?  (complex, complex(8), real, real(8), ...)

Jim Dempsey

[François-Xavier]

Complex(8) and real(8).

I will try your suggestion about handler.

Sincerely yours and thank you