- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 :)
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Compile your modules with one (or more) of: -auto, -qopenmp, -recursive
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
![](/skins/images/45C6C2D737ED71F4C51F0145C8CB1E9C/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page