/Qsave not set in conversion from CVF to IVF

[danhoyt]

This is really just a question, rather than a problem.

While trying to solveother problems converting projects from CVF to IVF, I found that some of my problems were caused by a fundamentally different default behavior between the two regarding variable saving. Thanks to this forum, BTW -- I never would have figured that out without the information transfer here.

However, I didn't see a reference to resolving this issue, which certainly comes up when migrating CVF to IVF. So I have to ask:

CVF's default seems to be IVF's optional "/Qsave". If this is the case, shouldn't the IVF converter automatically add the "/Qsave" compiler option to its converted projects? Or has this behavior already been changed since I converted these projects a couple years ago?

-Dan Hoyt, Senior Systems Architect, Technology Service Corp, Colorado Operations

[Steven_L_Intel1]

I agree and will suggest that this be changed.

[Jugoslav_Dujic]

While we're at the topic, I must say that I'm a bit disappointed on development of the project converter. My main concern is that it blindly assumes the defaults. See support issue #262840 (three years ago!). At minimum, the converter should ask the user about:

* which calling convention to apply (CVF or default), as well as string passing
* whether to apply /Qsave as well
* to which .h files the automatic conversion to .fd should be performed (yes, I often have auxiliary .h files in the project that I don't want to convert)

[Steven_L_Intel1]

Jugoslav, I'll bring this to the attention of the development team.

[fridman__sergey]

Quoting - danhoyt

With respect to the compiler option "All Variables SAVE (/Qsave)" in the pesense of allocatable arrays, it looks like version 11 of Intel Fortran behaves inconsistently with Fortran standard as well as with its own help articles (see the help item "Deallocation of Allocatable Array"). In the absense of explicit deallocate operation this version of fortran forces preservation of internally-defined allocatable arrays within subroutines even after returning to the calling unit. Intel Fortran help claims that it can be happening only when the allocatable array is defined with explicit SAVE attribute. Version 9 of Intel Fortran compiler used to react on "All Variables SAVE (/Qsave)" compiler option differently. It would cause saving of internal static variables, while releasing internal allocatable arrays upon returning from subroutines.
Is it a bug or is it a feature?
Is there a compiler option which is equivalent to the option "All Variables SAVE (/Qsave)" of version 9?

[Steven_L_Intel1]

/Qsave applies the SAVE attribute to all local variables, including allocatables. This is the intended operation. Please point out specific documentation and support articles that say otherwise and we'll get them fixed.

I don't know if 9.1 behaves properly in this respect.

And since you've done the favor of resurrecting this thread, I'll mention that as of version 11, converting a CVF project does enable /Qsave.

[fridman__sergey]

Quoting - Steve Lionel (Intel)

/Qsave applies the SAVE attribute to all local variables, including allocatables. This is the intended operation. Please point out specific documentation and support articles that say otherwise and we'll get them fixed.

I don't know if 9.1 behaves properly in this respect.

And since you've done the favor of resurrecting this thread, I'll mention that as of version 11, converting a CVF project does enable /Qsave.

This modification in IVF 11 adds some addtional pain to transition from CVF, because you are likely to get run-time errors "allocatable array already allocated". My understanding was that /Qsave had been introduced into IVF 9.1 in order to be compatible with defaults of CVF, MicrosoftVF (as well as all earlier versions of Fortran that I was familiar with). In CVF the default was to save all local static variables and to release all allocatable arrays upon exiting a subroutine. Local allocatable arrays could be saved within a procedure only if they are declared with explicit SAVE attribute in the procedure (regardless of compiler settings, as far as I remember). IVF11 help seem to suggest that IVF11 trats local allocatable arrays on the same manner as CVF used to treat them. For example the IVF11 help article "Allocation of Allocatable Arrays" states:
'If an allocatable array does not have the SAVE attribute, it has the status of "not currently allocated" at the beginning of each invocation of the procedure. If the array's status changes to "currently allocated", it is deallocated if the procedure is terminated by execution of a RETURN or END statement'
There is no word that compiler settings may modify the above rool of code interpretation.
A similar statement can be found in the IVF11 help article "Deallocation of Allocatable Array"...

[Steven_L_Intel1]

You're absolutely right - we (that's the Royal We here because it was I who put in the request to add /Qsave to converted CVF projects) did not consider the effect this would have on local ALLOCATABLE variables. Ouch!

Unfortunately, there is not a switch that matches the CVF semantics of local, non-allocatable variables being SAVEd. The simplest thing, I suppose, is to turn off the /Qsave option (it is just set when converted, you can turn it off) and then add SAVE to any variables that should have it.

I'll look at the places you note and see if they need to be corrected. Sorry for the troubles - our intentions were good.