forrtl: error (65) with Release Version: debug version OK

forrtl: error (65) with Release Version: debug version OK


I am getting "forrtl: error (65): floating invalid" with the release version, but the program runs OK with thedebug version and the same input. It is not easy to send the program to Intel or isolate the code, so I am looking for general guidance. I have removed optimization from the release version, but it still gives me the error. I also changed to the safer-sounding floating-point options, but the error remains.

I am trying to compare the release and debugcompiler options by looking at the vprojf file. One difference I find is that the release version hasInitLocalVarToNAN="true", but not the debug version. How do I set this to true for the debug version (using VS2010)? What I am trying to do is reproduce the problem in the debug version, so I can understand its cause, but I have not been able to do it.

BTW, I am using the latest Intel Fortran Composer.

Thank you,


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

You don't want to use that option, which corresponds to /Qtrapuv (under Data > Initialize stack variables to an unusual value). It does not do anything useful, but if you want to turn it on in Debug, that's where. It certainly does not set anything to a NaN, despite the name in the project file. (The original description of that option said it set variables to NaN, but that wasn't the implementation.)

I suggest instead you set Floating Point > Floating-Point Exception Handling to "Underflow gives 0.0; trap on other IEEE exceptions (/fpe0)". This will most likely cause the program to stop when it would otherwise produce a "floating invalid", giving you a better chance of seeing where it comes from.

Most likely, though, you have some other error that is revealed by optimization, such as use of an uninitialized variable. But give that a try.

Retired 12/31/2016


Thank you. I managed to get the debug version to crash, using your suggestion. Now, my problem is that the call stack is not showing the fortran code for the subroutine where the error is happening. All it shows is thecall to that subroutine fromthe main program.

By the way, the error message I get is:

Unhandled exception at 0x778a15de in HAZ_Table.exe: 0xC00002B4: Multiple floating point faults.

I don't recall ever seeing the "Multiple floating point calls"

Also, the traceback shows the following:

Image PC Routine Line Source
HAZ_Table.exe 01091246 _expf.J 350 expf_wmt.c
HAZ_Table.exe 0102E505 _CALC_HAZ_CAV 361 HAZ_Table.f
HAZ_Table.exe 0102C941 _MAIN__ 234 HAZ_Table.f
HAZ_Table.exe 010EE443 Unknown Unknown Unknown
HAZ_Table.exe 01098D19 Unknown Unknown Unknown
HAZ_Table.exe 01098BDF Unknown Unknown Unknown

I never recall seeing expf_wmt.c above the fortran code.

Any suggestion on how I can drill down to the subroutine in question? Did I mess up my settings?

Sorry if my questions are too elementary. I am trying tograduate fromCVF, but I keep encountering problems like this.

Thank you,



I was able to cause the crashto appear and disappear in either debug or release mode by turning /Qtrapuvon and off. This made me even more confused and made me think there was some un-initialized variable. The change you suggested in the settingsfor the underflow handling alsocaused the debug versionto crash. Still, I was not able to identify the specificline of code where theprogram was blowing up.

I figured out the problem using CVF. An error in the logic was causing an exponential overflow. I still do not understand why /Qtrapuv affected the behavior of the program (it should have crashed with or without it). It is also disappointing that the latest Intel compiler +MS debugger never gave me the actual instruction where the program was blowing up.



I'd like to see the program in the mode where it was failing. I think the traceback did show you the point of error, but it was inside a math library routine. Setting /Qtrapuv does change the code generator behavior somewhat, so it may have helped show the error.

Retired 12/31/2016

I believe if you look at this line:

HAZ_Table.exe 0102E505 _CALC_HAZ_CAV 361 HAZ_Table.f

361 in HAZ_Table.f

you will find it calling an EXP function with an invalid number or similar.

Leave a Comment

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