Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

How to disable implicit "save" attribute for variables declared in a module?

George_G_
Beginner
1,452 Views

Hi,

I'm dealing with a modular code in which several instances of a FORTRAN subroutine may coexist. The trouble is, these subroutines use a FORTRAN module (which has both variables and methods) - and each call is performed with different input. The general design requires these subroutines to work without influencing each other.

Before Intel 13, everything was working fine; with Intel 16, I see that these subroutines "communicate" to each other through the FORTRAN module. Somehow, the variables declared in the module do not go out of scope and behave (all of them) as if they were declared "save". After some research, I found this topic (unfortunately, closed)

https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/487313

where it is stated

Prior to F2003, I think, if you didn't say SAVE on module variables, they became undefined if that module was not USEd in any active call tree. This is similar to the way COMMON was defined in the past, allowing for "overlay" implementations. The standards committee had a burst of sanity and decided to make module variables implicitly SAVE, at the same time as variables with initialization were also made implicitly SAVE. Practically speaking, though, this had no effect - I don't know of a single implementation that didn't treat module variables as SAVE already.

Would you please point me to a solution to disable this feature (in other words, NOT treat all the module's variables as "save" unless explicitly declared as "save")? If this is not possible, the whole code needs to be modified quite a lot ...

Cheers,

George

PS It does not matter how fiddly the solution is, I just need it to be stable :)

0 Kudos
8 Replies
FortranFan
Honored Contributor II
1,452 Views

Are you facing any problems?  You should try to provide a reproducer to Intel (or here in the forum) that show the problems.  You may want to let any connection with module variables and their attributes fall out of the analysis based on which you can then develop a suitable solution, rather than shortcircuiting the analysis with something non-standard.

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,452 Views

Compile your modules with one (or more) of: -auto, -qopenmp, -recursive

Jim Dempsey

0 Kudos
George_G_
Beginner
1,452 Views

jimdempseyatthecove wrote:

Compile your modules with one (or more) of: -auto, -qopenmp, -recursive

Jim Dempsey

Hi Jim,

I tried them all, and all combinations. It does help with the variables not declared inside the module. Whatever is declared in the module remains "save"

 

Cheers,

George

 

0 Kudos
JVanB
Valued Contributor II
1,452 Views

There is no way do disable the SAVE attribute because there are some entities that require some kind of initialization when they come into scope. Variables with the ALLOCATABLE attribute and user-defined types with default initialization come to mind. I can't recall what is supposed to happen with user-defined types with such components, maybe them as well. To achieve this reinitialization the Fortran processor would have to keep track of when a module went out of scope, something that was never required for COMMON blocks.

Depending on context, you might be able to group all of your module variables into a user-defined type so that you could have complete control of the scope of each instance of the user-defined type. Or maybe if the usages are in different threads you could try marking the module variables as THREADPRIVATE.

 

0 Kudos
Steve_Lionel
Honored Contributor III
1,452 Views

Nothing has changed here in the implementation. The only difference is the wording the standard uses to say whether or not module variables remain defined. Prior to Fortran 2003, the standard used words based on the ancient "overlays" implementation possibility, though I don't know of any Fortran compilers that did anything different. Fortran 2003 allowed programmers to now assume that module variables that didn't have SAVE remained defined, though "undefined" simply means you don't know what the value is.

If your program somehow assumes that module variables will revert to some initial value, that has never, ever been the case. Certainly, using module variables works against the notion of no global context.

0 Kudos
George_G_
Beginner
1,452 Views

Steve Lionel (Ret.) wrote:

Nothing has changed here in the implementation. The only difference is the wording the standard uses to say whether or not module variables remain defined. Prior to Fortran 2003, the standard used words based on the ancient "overlays" implementation possibility, though I don't know of any Fortran compilers that did anything different. Fortran 2003 allowed programmers to now assume that module variables that didn't have SAVE remained defined, though "undefined" simply means you don't know what the value is.

If your program somehow assumes that module variables will revert to some initial value, that has never, ever been the case. Certainly, using module variables works against the notion of no global context.

 

Hi Lionel,

what I was waiting to see is that (for example) one array I allocate in the first subroutine goes out of scope when the first subroutine goes out of scope. What I see is that the array is there when the second subroutine comes into scope, with the values set by the first subroutine.

In other words, I would have expected "save" to be the equivalent of "static". And if the variable is not individually declared as "static", it won't be. If I understand your answer correctly, this is not the case and cannot be done, as the whole "module" structure is "static".

Final question: would it be possible at least to declare (in the module) something as "mutable", or equivalent?

Cheers,

George

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,452 Views

Fortran does NOT auto-wipe ALLOCATE'ble arrays. If you allocate an array, populate it, deallocate it, then immediately allocate it again. There is a high probability that the same block of data gets allocated --- thus data looks preserved. If you allocate, and populate other arrays after the deallocation (of your test array), then reallocate your test array, you should see what is commonly called "junk data". In Fortran-speak this is undefined data.

Jim Dempsey

0 Kudos
Steve_Lionel
Honored Contributor III
1,452 Views

SAVE does indeed mean what you call "static". and module variables, at least in Intel Fortran (and DEC Fortran) have always been static.

I don't know what you mean by "mutable" here. If your subroutines want to be independent of other procedures, they should not use module variables. One common implementation is to have the caller pass a "handle" which the procedure uses to keep track of its own instance data.

 

0 Kudos
Reply