forrtl: severe (193): Runtime Check Failure

[ghgosuok]

I have migrated a CVF project to IVF by creating a new project in IVF. The source code compiles with no errors or warnings, but when I execute the program I get a runtime error: severe (193): Runtime Check Failure. The variable 'READFF$I' is being used without being defined. There is no variable by that name in my source code, but I have a subroutine named READFF. The exact source code compiles and runs with no errors or warnings in CVF. I am using IVF 11.1.048. Any ideas?

[TimP]

Quoting - ghgosuok

Runtime Check Failure. The variable 'READFF$I' is being used without being defined. There is no variable by that name in my source code, but I have a subroutine named READFF. The exact source code compiles and runs with no errors or warnings in CVF.

It seems to have found an undefined variable I in READFF. If you aren't using IMPLICIT NONE, this would have been taken by CVF as INTEGER,SAVE :: I
Among the reasons for such compiler warnings are that it's a common source of bugs due to typos, so you should examine that subroutine carefully.

[Steven_L_Intel1]

The variable may not be named I - in some older versions of IVF, this message would use I for all integer variables. That is fixed in the current release. Which version are you using?

The error you're getting is a run-time check for an uninitalized variable. This message is almost always accurate (if it is given.)

[ghgosuok]

Quoting - Steve Lionel (Intel)

The variable may not be named I - in some older versions of IVF, this message would use I for all integer variables. That is fixed in the current release. Which version are you using?

The error you're getting is a run-time check for an uninitalized variable. This message is almost always accurate (if it is given.)

Steve, I will check for variables other than "I", however I am using IVF 11.1.048. I am using "Implicit None" and I have declared "I" as and integer.

[Steven_L_Intel1]

If you're using 11.1.048, then I will be the variable name. Check to make sure that the value of I has been set before it is used.

[ghgosuok]

Quoting - Steve Lionel (Intel)

If you're using 11.1.048, then I will be the variable name. Check to make sure that the value of I has been set before it is used.

Steve, the value of I is set before it is used. Upon entry into the subroutine, if a certain condition is not met, then the first instance of "I" does not have a value set, but it is not used. If the other condition is met then "I" is used but in that case it has already been assigned a value. However, I went ahead and assigned a hard value to "I" at the beginning of the subroutine just to see what would happen. Then the error messagerefers tothe variable 'READFF$K'as being used before it has been assigned a value, but clearly in the program k has been assigned a value. If I assign an arbitrary value to k, then the error message refers to another variable "ki" but this variable has also been assigned a value before it is used. If I keep assigning values to these variables at the beginning of the subroutine, eventually the error message does not appear, but with the arbitrary values, the program crashes. I do not understand why the error message appears when the program has clearly assigned a value to the variables before they are used. As I mentioned the code runs fine in CVF (which I tried again to verify). Is there a way to turn off the Runtime Check? Do you have any other suggestions? Thanks for your assistance.

[Steven_L_Intel1]

That you tried the code in CVF is not proof of correctness. Yes, you can turn off the check - under Fortran > Run-Time there's the option.

Would you be willing to share the source so that I can look into the problem?

[Garry_G_]

Quoting - Steve Lionel (Intel)

That you tried the code in CVF is not proof of correctness. Yes, you can turn off the check - under Fortran > Run-Time there's the option.

Would you be willing to share the source so that I can look into the problem?

Steve, I tried to turn off the runtime check by including "/check:nouninit" in the ifort.cfg file, but got the same runtime error message. I also tried "/nocheck". Based on the documentation /check:nouninit should have eliminated the runtime check for variable initialization. Do you know why the runtime check is apparently still actve? I know the ifort.cfg file is in the correct path since I had a typo the first time and got a compile time error message. I could send you thecode for the subroutine where the runtime error is occuring, if that would be helpful. The entire code to make the program actually execute consists of three executables (25,000+ lines of code) and is compiled under a proprietary environment (Winteracter). I have distributed this engineering program for years using CVF and the program execution is as expected, with more than 1,200 users. However, I very much want to get it migrated to IVF. Can you set up a private thread for submission of the subroutine source code? However, first I wantto try it with the runtime check for variable initialization turned off. Thanks for your help.

[Paul_Curtis]

The non-implementation of default SAVE semantic is a major difference between CVF and IVF -- you need to put explicit SAVEs on all quantities where this behavior is needed. This is especially important for Windows proc functions where each WM_ message is a different call and things defined in WM_INIT need to be preserved for subsequent manipulation. If you are not running your own procs (Winteracter?), then that code may need to be updated with SAVEs and recompiled in IVF, as well as your own code.

[Garry_G_]

Quoting - Paul Curtis

The non-implementation of default SAVE semantic is a major difference between CVF and IVF -- you need to put explicit SAVEs on all quantities where this behavior is needed. This is especially important for Windows proc functions where each WM_ message is a different call and things defined in WM_INIT need to be preserved for subsequent manipulation. If you are not running your own procs (Winteracter?), then that code may need to be updated with SAVEs and recompiled in IVF, as well as your own code.

Thanks Paul, I will take a look at SAVEs. The Winteracter is a development environment and GUI development toolset. It is fully compatible with IVF and works fine with other applications that I have. Sorry for the confusion on Winteracter. Do you have a little snippet of code example that you could share showing the implementation of SAVE that you are referring to? That would be helpful to me at this point. Thanks !

[Steven_L_Intel1]

As Paul says, CVF applied SAVE semantics by default to local variables, but Intel Fortran does not. You can ask for the CVF behavior by adding /Qsave. It's possible that this is related to the error, but adding /Qsave will definitely disable the run-time check for local variables - as will not specifying /check:uninit.

[Garry_G_]

Quoting - Steve Lionel (Intel)

As Paul says, CVF applied SAVE semantics by default to local variables, but Intel Fortran does not. You can ask for the CVF behavior by adding /Qsave. It's possible that this is related to the error, but adding /Qsave will definitely disable the run-time check for local variables - as will not specifying /check:uninit.

Steve and Paul, adding /Qsave solved the problem!! Paul I did not understand that you were talking about the SAVE attribute for variable assignments. I was thinking it was something else due to some of the IVF semantics that you mentioned. I will add the SAVE attribute to my future programs/code revisions related to variables. Anyway, thank you both. I now have all my programs migrated to IVF !!

[Paul_Curtis]

While /Qsave appears to restore the CVF behavior, much tutelage in this forum from Steve and others has pointed out that /Qsave has many surprising and probably undesired side effects, and forces saving of objects (such as allocatable arrays) which you probably didn't want to save. I have been along this path, and have abandoned /Qsave in favor of adding explicit SAVEs to all the local quantities which need to persist. And, again, this is of particular importance for Windows procs.

[Steven_L_Intel1]

If you store Windows handles in module variables, you don't have to worry about SAVE.

[Paul_Curtis]

Quoting - Steve Lionel (Intel)

If you store Windows handles in module variables, you don't have to worry about SAVE.

True, but many more objects than just handles are involved for windows or dialogs of even modest complexity, and most of them sensibly have proc rather than modular scope. For example, if a window's rect is acquired when the window is created, and then a subsequent resize message operates on that rect, the original rect needs to be preserved. Every CASE in a Windows proc represents a separate invocation of the proc, so basically any object defined or used in one message's code block needs to be preserved if it appears in any other message's code block. This is why I suggested that the OP make sure that his Winteracter code was specific to IVF (presumably with lots of SAVEs) and not simply carried over from CVF. It has been my experience that Windows procs exhibit immediate symptoms of missing SAVEs much more dramatically than regular code.

[Steven_L_Intel1]

In this era of multithread programming, I'm loathe to recommend SAVE or even global variables to save context. I admit that I have not done a lot of complex Windows programming, but the code I have worked on has not required local variables to be SAVEd.