Save-statement

[nijhuis]

In a received piece of Fortran90 software, I was confronted with a Save-statement (without a list of variables) in the declaration part of a module. This Save embarrasses me, because I think that all variables in a module are automatically saved.

Do I miss a rule or is a Save-statement in a module indeed superfluous?

Guus

[Jugoslav_Dujic]

Basically, it's superfluous.

Language lawyers could tell better if they're allowed to be discarded in theory, but no modern compiler does that and I think it's very unlikely that any future one would, as "unsaving" them is simply impractical. I've heard stories of old compilers which discarded unused COMMON blocks (when no subroutine using it was in scope) on some ancient systems which used "memory overlays" -- but I guess it was before I was born or so. I guess this module-variables story, if at all, goes to the same domain (and such computers certainly don't have F90 compilers available :-) ).

Jugoslav

[Steven_L_Intel1]

The SAVE rules in Fortran allow for the possibility of an implementation that does not keep the whole program in memory, thus the rather odd rules about SAVE for COMMONs and in MODULEs. I agree that in most cases these are superfluous. (SAVE in a main program is a no-op, but the language allows it and says it should be ignored.)

SAVE in general does have uses - it is an optimization aid to the compiler and also is a correctness and human comprehension aid. I recommend its use and not relying on implementation defaults.

[wu_internet]

I am experiencing a nightmare right now for "No Save-staetment".

Within a big project, the local variables are intended to be used with the "save" attribute, but they are used in a default way, the code does not have any "SAVE" statement. It works fine with Compaq Fortran. Now under Intel Fortran, I found they are not saved at all, every time when get into the subroutine, the local variables have been changed. I build a small project try to replicate the problem, but it can not be replicated. Therefore, I can not submit the bug report. The big project code works consistently, i.e. the default SAVE does not work at all with thelocal variables. Anyone have the similar experience I'd like to discuss about this.

Regards,

David

[TimP]

If I understand you, you are adding a SAVE statement with the intent of applying SAVE to all variables declared in that subroutine. A possible way of generating a bug report would be to test whether declaring all variables SAVE by name is working. If that works, you have demonstrated that the wholesale SAVE is suspect.
Then, you could try removing groups of variables from SAVE by name, and determine which are being missed by the wholesale SAVE. Then, a report on premier.intel.com, where you file the source code of that subroutine, your findings, and your compile options might prove useful.

[hansr]

After transfer from CVF (or from the HOST ??) to Intel8 we also had problems with no longer saved local variables. In some cases we had success withthe setting of compiler and linker options :

Fortran->Data->Local Variable Storage = All Variables SAVE

Regards

Hans

[wu_internet]

Thanks, Han

I believe that is the case for me. I will try this out.

Regards

David

[Paul_Curtis]

My experience confirms that of wu_internet and the other posters: the default SAVE behavior of IVF is very different from that of CVF, and also seems to depart from (at least, my) expectation of the Fortran default. Adding 'SAVE' statements to IVF modules doesn't always seem to work, either.

What does work is adding the /Qsave compiler directive to all modules. This totally fixes the problem and restores the default behavior of CVF.

[nijhuis]

Paul-Curtis remarks:

"Adding 'SAVE' statements to IVF modules doesn't always seem to work, either."

I don't know what is the ground for this statement. I just concluded that it was a good programming practice to include a SAVE-statement in each module.

Steve says this in a prior message in this thread and it was confirmed to me in the book "FORTRAN 90/95 for Scientists and Engineers" (S.J. Chapman) on page 341.

I admit it was a surprise for me that it is necessary because I read that variables in a module have automatically the "PUBLIC"-attribute and so I thought that the value ofsuch a variable would be unchanged for the whole program , unless you do an explicit change. I also never had a problem using it without SAVE and I use a lot of modules.

But apparently you must make a distinction between accessibily of a variable and value of a variable.

So I 'm going to include the SAVE statements in all my modules, because I never want to be dependent of a compiler for such things.

So I hope that your first statement about SAVE is not correct. Also I don't want to be dependent of a compiler directive.

Guus

[Steven_L_Intel1]

There is no relationship between the SAVE status of a variable and its accessibility.

If a variable has the SAVE attribute, its definition status is preserved when the declaring program unit "goes out of scope". Ordinarily, this means a routine returning, but in the context of modules and common blocks, it also applies if at some point in the program no active program unit USEs the module or declares the common block. That said, I never use SAVE for common blocks and module variables in my own programming, since every implementation I know of today treats such variables as if they were SAVEd.

[Paul_Curtis]

To clarify my earlier post, SAVE is either broken, or inconsistently functional in IVF. After migrating a large multimodule project from CVF, which (eventually) compiled and linked fine,many bizarre performance errors in formerly perfect code were traced to the lack of SAVE behavior. Adding generic SAVEs to modules does not accomplish anything. AddingSAVE statements for specific variables sometimes works, but this performanceis sporadic and unpredictable. Adding the /Qsave compiler directive restores the correct and expected behavior, globally. This looks to me like a bug in IVF.

[Steven_L_Intel1]

I have verified that the behavior is inconsistent with the documentation (and the CVF behavior.) The issue is under investigation. /Qsave is one workaround, though good programming practice would say to give variables you want saved the SAVE attribute explicitly.

[billwrightster]

My example may shed some light on this issue.A variableV(without "SAVE" or "SAVE V") set once, on the first execution of subroutine A, remains "saved" on 305375 subsequent calls to A (of about 1,000,000 intended); on the 305376th call it has become (and remains) zero thereafter. With SAVE V or just SAVE, the program runs to completion with V retaining its proper value.

bill wright