Given the following code:

module simple

implicit none
save

real(8) :: x = 0.0d0

contains

subroutine accum(dx)
implicit none

real(8), intent(in) :: dx

x = x + dx

return
end subroutine accum

end module simple

I seem to be having difficulty with Intel Fortran 10 not "saving" the
modified values of x after every call to the subroutine accum.
Because x is a shared module variable I thought the save statement
would apply to x even if x is modified in a module procedure.

jel jhuapl.edu> wrote:

...

Yes, you should expect that per the standard. But I'd say that your
guess that there may be some other problem with the code is all but
certain to be correct. The odds that adding an explicit SAVE statement
"fixed" it seem low. I'd say more likely is that this had nothing to do
with it, but that you noticed an apparent coincidence (particularly
since you say that the behavior is only occasional anyway).

jel wrote:

Craig Powers wrote:

Oh. I missed the fact that the added SAVE statement was a
procedure-level one instead of a module-level one. That makes a big
difference. If you add a procedure-level SAVE, that would effectively
declare a *DIFFERENT* variable of that name in that procedure. It would
have nothing to do with the module variable of the same name.

Richard Maine wrote:

What is the effect of the module-level SAVE? I thought all module variables were automatically SAVEd.

Gib Bogle wrote:
...

Nope. That's what I've usually argued *should* be the rule,
but Fortran doesn't say that. Unless you have the save attribute,
all module variables become officially undefined when the
last USE for the module (the one highest in your call sequence)
goes out of scope.

Having to remember whether a module USE is still in scope
or not is something many users are not particularly good at.
Those that *can* keep track of such things would rather
not be required to do so. That's why I think module variables
should always be considered SAVEd. The definition of
Fortran should be changes to require it.

--
J. Giles

On Tue, 10 Jun 2008 03:38:59 GMT, James Giles wrote:

This sounded like an awfully strong statement, what with "should" in it,
but that was exactly what Richard claims. Does anyone claim to the
contrary?

Ron Ford wrote:

The rules for named COMMON allow named common to be become undefined
if no routines referencing it are active. As I understand it,
that used to happen on some systems with overlays. It seems to
me that MODULE inherited this attribute from COMMON.

For named COMMON, and I believe MODULE, the choices are to put
such statement in the main program or use a SAVE statement for it.
With the larger available memory in machines today, it would
not seem too much to change the standard such that both were
always SAVEd.

-- glen

Gib Bogle auckland.no.spam.ac.nz> wrote:

To declare all module-level variables to be saved.

No. That's just plain wrong. It is possible, even likely, that you are
confusing typical implementations with the requirements of the standard.
The typical implementation of module-level variables is for them to be
statically allocated, in such a way that they behave as though they were
saved, even if they don't have the save attribute. However

1. This is not what the standard requires. Such compilers are standard
conforming, but code that depends on the behavior is not.

glen herrmannsfeldt ugcs.caltech.edu> wrote:

While there is certainly simillarity between the situation for common
and modules, the above seems to carry that simillarity farther than it
goes.

There is no way to specify a SAVE attribute for a module. In a module,
it is the individual variables that are saved (or not); the module as a
whole cannot have a SAVE attribute. In a common, it is the common block
as a whole that is saved (or not). The individual variables in a common
block cannot be given the SAVE attribute.