views:

394

answers:

4

I've read it's entry in the language reference (Intel's), but I cannot quite grasp what it does. Could someone in layman's terms explain it to me, what it means when it is included in a module ?

A: 

Normally, local variables go out of scope once execution leaves the current procedure, and so have no 'memory' of their value on previous invocations. SAVE is a way of specifying that a variable in a procedure should maintain its value from one call to the next. It's useful when you want to store state in a procedure, for example to keep a running total or maintain a variable's configuration.

There's a good explanation here, with an example.

ire_and_curses
Uhmm, could you give an example of that ? If I understand correctly, if I declare SAVE in a module, its variables cannot change values in subroutines ?
Friedrich Schwartz
@Friedrich Schwartz: Not quite. You can still set new values, but if you were to inspect the value of the variable before setting it, you would see the last value you had set the variable to. Without `SAVE`, you would see 'undefined'. Working through a simple example should make it clearer.
ire_and_curses
+1  A: 

In principal when a module goes out-of-scope, the variables of that module become undefined -- unless they are declared with the SAVE attribute, or a SAVE statement is used. "Undefined" means that you are not allowed to rely on the variable having the previous value if you again use the module -- it might have the previous value when you re-access the module, or it might not -- there is no guarantee. But many compilers don't do this for module variables -- the variables probably retain their values -- it isn't worth the effort for the compiler to figure out whether a module remains in scope or not and probably module variables are treated as global variables -- but don't rely on that! To be safe, either use "save" or "use" the module from the main program so that it never goes out of scope.

"save" is also important in procedures, to store "state" across invocations of the subroutine or function (as written by @ire_and_curses) -- "first invocation" initializations, counters, etc.

subroutine my_sub (y)

integer :: var
integer, save :: counter = 0
logical, save :: FirstCall = .TRUE.

counter = counter + 1

write (*, *) counter

if (FirstCall) then
   FirstCall = .FALSE.
   ....
end if

var = ....

etc.

In this code fragment, "counter" will report the number of invocations of subroutine x. Though actually in Fortran >=90 one can omit the "save" because the initialization in the declaration implies "save".

In contrast to the module case, with modern compilers, without the save attribute or initialization-on-a-declaration, it is normal for local variables of procedures to lose their values across invocations. So if you attempt to use "var" on an later call before redefining it in that call, the value is undefined and probably won't be the value calculated on a previous invocation of the procedure.

This is different from the behavior of many FORTRAN 77 compilers, some of which retained the values of all local variables, even though this wasn't required by the language standard. Some old programs were written relying on this non-standard behavior -- these programs will fail on the newer compilers. Many compilers have an option to use the non-standard behavior and "save" all local variables.

LATER EDIT: update with a code example that shows incorrect usage of a local variable that should have the save attribute but doesn't:

module subs

contains

subroutine asub (i, control)

   implicit none

   integer, intent (in) :: i
   logical, intent (in) :: control

   integer, save :: j = 0
   integer :: k

   j = j + i
   if ( control ) k = 0
   k = k + i

   write (*, *) 'i, j, k=', i, j, k

end subroutine asub

end module subs

program test_saves

   use subs
   implicit none

   call asub ( 3, .TRUE. )
   call asub ( 4, .FALSE. )

end program test_saves

Local variable k of the subroutine is intentionally misused -- in this program it is initialized in the first call since control is TRUE, but on the second call control is FALSE, so k is not redefined. But without the save attribute k is undefined, so the using its value is illegal.

Compiling the program with gfortran, I found that k retained its value anyway:

 i, j, k=           3           3           3
 i, j, k=           4           7           7

Compiling the program with ifort and aggressive optimization options, k lost its value:

 i, j, k=           3           3           3
 i, j, k=           4           7           4

Using ifort with debugging options, the problems was detected at runtime!

 i, j, k=           3           3           3
forrtl: severe (193): Run-Time Check Failure. The variable 'subs_mp_asub_$K' is being used without being defined
M. S. B.
A: 

Posting this as an answer to M.S.B. because the lack of formatting in comments would probably make a pig's breakfast out of the whole thing:

First, thanks for answering, both of you. I appreciate it.

If I understood right;

  subroutine save(j)
     implicit none      

     integer :: i = 0, j
     save i

     i = i + j
     write(*,*)i

  end subroutine save


  program test_save
     implicit none

     integer :: j

     j = 1

     call save(j)
     call save(j)

  end program test_save

were it not for the SAVE statement in the above little example, the variable i (the value of the variable) would be "lost" after the first call of save subroutine. Thanks to it, it retains it's value - "1" in this case, and because of it, it increases to "2" during the second call.

Have I gotten it right ? Near maybe ?

Friedrich Schwartz
Yes, the SAVE statement causes the variable i to retain its value. One subtly is that in this example, in Fortran 90, the save statement is optional -- "save" automatically applies because "i" is initialized in a declaration. The save statement would be mandatory in FORTRAN 77.
M. S. B.
A: 

A short explanation could be: the attribute save says that the value of a variable must be preserved across different calls to the same subroutine/function. Otherwise normally when you return from a subroutine/function, "local" variables lose their values since the memory where those vars were stored is released. It is like static in C, if you know this language.

ShinTakezou