Save attribute for module variables

The rules are relatively clear: “On return from a subprogram that accesses a variable in a module, the variable becomes undefined unless the main program accesses the module, another subprogram in execution accesses the module, or the variable has the SAVE attribute” (Metcalf et al.).

For me this means that all variables in a modules get the SAVE attribute, if I include in the main program a statement

“Use ABC”

However, it happened several times to me that this was not sufficient. I had to add a Save statement in the main program:

“Use ABC ; SAVE”

in order to avoid undefined variables.

Recently, this happened again. Unfortunately, I cannot condense this problem to a small program for presentation in this forum although the module is not complicated. But it includes allocatable arrays, which are allocated in other program units and none of the variables has explicitly the SAVE attribute.

My question is whether somebody has made similar experiences.

Klaus Lassmann

PS. Of course I have looked into the dump list of the module, which I do not really understand. What I see is that only a few variables have actually the SAVE attribute whether I use the SAVE statement in the main program or not.

Hi Klaus

I do not exactly understand the problem in the previous post. However, I did made some strange experiences in the past which was related to the debugger. Questions: 1.) what is the version of your compiler and 2.) could you perhaps get the code below to produce your error?

program save_demo
    implicit none
    real :: x 

    do 
    write(*,'(A$)') 'Geben Sie einen Wert fuer x ein (0 fuer Programmende): '
    read(*,*)  x
    if ( x == 0.0) exit
    call ausgabe(x)    
    end do

end program save_demo
    
subroutine ausgabe(x)
    implicit none
    real          :: x
    integer, save :: i
     
    write(*,*)
    write(*,*) 'Anzahl der bisherigen Aufrufe dieser subroutine:', i
    write(*,*) 'eingegeben wurde: x = ', x
    write(*,*)
    i = i +1 
end subroutine ausgabe

Example from https://srv.rz.uni-bayreuth.de/lehre/fortran90/vorlesung/V07/save_demo.f90

I use the latest FTN96 version.

I suspect that the rule descibed in my post is not correctly -or may be not completely- implemented. The code works, if -as last statement in the module- a SAVE statement is included. This Save should not be necessary since the module is assessed in the main program. However, without the SAVE statement in the module an undefined variable is reported which has clearly been defined.

Your code has a simple programming error. This has nothing to do with my problem.

KL

Klaus,

I do not think you are correct in claiming that variables should be undefined outside the scope of a Module. This claim, also associated with COMMON that is only accessed in subroutines, is not a necessary action of the compiler. I think the standard says that the variables do not have to be retained. However I know of no compiler that has implemented this, and indeed it makes no sense to me to implement this option, as it defeats the basic purpose of a MODULE or COMMON. If anyone has the discussion as to why a MODULE should not automatically have the SAVE attribute, I'd love to see it. Implementing this feature would create a lot of problems for programmers and make Fortran less effective. Back when overlays were required, (pre Fortran 90/95), the save status of common was a more significant issue, but since then, save should be the default.

John

John,

may be that I expressed myself not clear enought.

I am arguing, that according to the rules the variables in a module should get automatically the SAVE attribute if the module is accessed by the main program. Fortran 95 rules do not say that all variables in a module get automatically the SAVE attribute!

I have no idea of how such rules are implemented in a specific compiler. But a user should rely on a correct implementation according to the Fortran 95 specifications. Could we get an answer from Silverfrost?

Klaus

Klaus,

The Fortran 95 Standard does NOT say that all variables in a module must not get the SAVE attribute for the case you have described. The compiler writer has the discression as to what to do in this case and all that I know of have applied a sensible interpretation.

John

For my understanding the variables in a module (or a common block) stays in memory as long as the program is executed - simply expressed. There is no need to use the SAVE attribute. However, this cammand can easily be interpreted wrong.

Klaus, thanks for the error in the above code. I fixed it and this example explains (as far as I know the only) the use of SAVE.

program save_demo
    implicit none
    integer :: i

    do
      write(*,'(A$)') 'Enter an integer (0 for stop): '
      read(*,*)  i
      if ( i == 0) exit
      call ausgabe(i)
    end do

end program save_demo

subroutine ausgabe(x)
    implicit none
    integer,intent(in) :: x
    integer, save      :: i=0

    if (i==0) then
      i = i+1
    endif
    write(*,*)
    write(*,'(A27,I4)') 'Calls to this subroutine:', i
    write(*,'(A27,I4)') 'entered value:           ', x
    write(*,*)
    i = i+1
    return
end subroutine ausgabe

Dear Jjgermis,

according to the Fortran 95 books that I use (M. Metcalf et al., fortran 95/2003 explaind; he was one the Fortran 9x developers) and an older book (C. Redwine, Upgrade to Fortran 90) your statement is wrong.

I guess that during the deveopment of Fortran 90 etc. there was a discussion about this item. The purists certainly wanted the same rules regarding the status of a variable for a module as for subroutines, whereas I suspect somebody had in mind, what most programmers believe (similar to your opinion). May be that the rule, that variables in a module get automatically the SAVE attribute, when the module is accessed in the main program, was a compromise satisfying both groups.

Something else is the implementation of such rules in a compiler and I have no ideas whether or not compiler differ in this aspect.

Best regards and good wishes for the New Year to all of you!

Klaus Lassmann

Perhaps for other readers: The Fortran standards can be view at http://www.fortran.com/ → Information → standard documents.

Dear Jjgermis,

I have looked into the references given in your post. Thank you very much for your efforts. Of course I could not study all Fortran Texts given, but what I found seems to support my point of view, which is actually not my 'point of view' but rather what I understood from reading Metcalf's book. What I found can be summarized as follows:

The entities in the scoping unit are “use associated” with the entities in the module. Thus if a module is associated to the main program, all entities of the module are treated similar to entities in the main program, which do not need any SAVE attribute. The SAVE attribute may appear in declarations in a main program but has no effect.

It follows that if the main program accesses a module, all module variables –once defined- should never get undefined, which is exactly what the SAVE attribute means.

If the module is only associated to a subprogram, a module variable may get undefined.

I would suggest to concentrate to the question how FTN95 behaves in such a situation. I still have some reasons to suspect that FTN95 is interpreting these questions in a different way.

Klaus

jjgermis,

Very interesting link, thankyou!

Leads to many other interesting and amusing links, see this article from 1982 http://simbalsyd.se/realprogrammers.html

John

Quoted from JohnCampbell I do not think you are correct in claiming that variables should be undefined outside the scope of a Module ... I think the standard says that the variables do not have to be retained.

I don't think Klaus *is *claiming that variables should (= must) become undefined except in the circumstances he listed. And in my way of thinking, variables that 'do not have to be retained' *do *become 'undefined'. By definition 😃 Perhaps it would be more accurate to say that their value 'should not be relied upon'.

As I understand it, the issue here for Klaus is not whether or not variables should become undefined except in specific circumstances. The issue is that in some circumstances, when using FTN95, some variables *do *become undefined in specific circumstances when they should not. He is querying whether or not FTN95 has completely correctly implemented the requirement for variables not to become undefined in specific circumstances when they should not.

And we also need to be careful to distinguish between 'undefined' = 'not to be relied upon' and 'UNDEFINED' = 0x80 in Salford CHECKMATEspeak. The distinction is important, because the latter is not something that can be seen simply by using SDBG - it requires a CHECKMATE build, or at least activation of the option to check for undefined variables. It's also important because any variable that would otherwise be undefined, that is set to the value UNDEFINED, *becomes * 'defined' i.e. explicitly set to a specific initial value by the program. It's also important because there is precedent for bugs in FTN95 that manifest in CHECKMATE code but not otherwise, or indeed vice versa.

So I think this thread is suffering from insufficient clarity of definition of terms 😉 . Klaus, can you please clarify your meaning of the term undefined, and whether you are instructing FTN95, one way or another, to check for undefined variables?

One observation on FTN95 support of the standard; If you look at a .map file you will see that all modules and common have a memory address allocated by SLINK at link time; ie all Modules and Common have a static address. I would say this is equivalent to not becoming undefined outside their scope. The example given earlier in this post applies to local variables, which without SAVE, have their memory address allocated (on the stack?) when the routine is called. The equivalent process for modules would be their address is allocated once the program enters their scope defining routine. I do not know of any Fortran compiler/linker which works in this way. This is more a feature of Slink, rather than FTN95. Again, If anyone knows the reason why this concept of Modules becoming undefined outside their scope is mentioned in the standard, I'd like to know the history. I remember needing this with overlay linkers in 1980's, but now with X32 and X64, it should only apply and be managed by allocated arrays.

John

If anyone knows the reason why this concept of Modules becoming undefined outside their scope is mentioned in the standard

I don't know anything about why this was expressed in the standard, but usually it's done to enable more flexibility to the compiler writers. And locals allocation is for the most part a very cheap operation (subtracting a precalculated thus fixed value from the stack pointer).

This thread has been going for a while now and perhaps I need to restate what I think.

1. I have undertaken to look into this issue when I can find time.
2. FTN95 does add the SAVE attribute in certain special circumstances when not specifically stated by the programmer.

I don't know at the moment whether the SAVE attribute (in these circumstances) is needed or justified. Certainly the compiler has the right to store data in whatever way it thinks fit. Compiler writers rule OK!

If the attribute is needed then I can give it a different name internally so that the user is not confused by the addition. If it is not needed then I can remove it.

Paul, I am not sure whether I really understand your answer.

Still I have the question whether it is a FORTRAN rule that a variable in a module may become undefined unless the main program accesses the modul. Is such a rule part of the Fortran 9x standard or not?

I came across this problem when I converted a FORTRAN 77 program to Fortran 95 that is in use since more than 20 years. The 'old' version has been run many times over years by FTN95. For the conversion I substituted the COMMON block by a modul into which I also integrated the old BLOCK DATA program. The conversion from fixed to free format was done by an own conversion program.

In your handbook the rules for the SAVE statement are given:

The following types of variables will automatically be static: -Any variable that appears in a SAVE statement. -Any variable in a program unit that contains a blank SAVE statement. -Any variable that appears in a DATA statement. -Any COMMON block variable. -Any variable that is initialised, e.g. INTEGER::I = 1

Nothing is said about modules, and it is clear why the old version is working under FTN95, since COMMON block variables are saved.

Why is this question of such an importance for me? In large programs it is sometimes very difficult to find errors. No doubt, FTN95 is an excellent compiler which helps the user best finding errors. Nevertheless, I am always getting very nervous when I come across a message such as 'undefined variable'. I do not speak about trivial cases in the early phase of development, I speak of a situation where an undefined variable is the result of more hidden and more complex errors. Only clear rules can be the guideline to find such errors.

In conclusion, I still suspect that there is a little inaccuracy in the behaviour of FTN95 and I hope that you find the time for checking.

11. Lassmann

PS. I regret that I cannot react to each contribution. In almost all cases my knowledge about compiler details is insufficient to comment.

Quoted from KL PS. I regret that I cannot react to each contribution. In almost all cases my knowledge about compiler details is insufficient to comment.

Klaus,

What you are asking is not simple. The contributions thus far make that quite clear. I think it's reasonable for Paul (and people who are trying to contribute helpfully) to expect that your knowledge about compiler details is at least sufficient for you to answer relevant questions that are thrown back to you.

It is my impression that your requests in the forum typically relate to what in English is referred to as 'dotting the i's and crossing the t's', and are precise to the point of pedantry. In my book, at any rate, this is a compliment not a criticism, in the context of programming. For some reason, in this thread, which relates to a potentially very big issue, you are being uncharacteristically and unhelpfully vague.

I asked you:

'can you please clarify your meaning of the term undefined, and whether you are instructing FTN95, one way or another, to check for undefined variables'

It seems reasonable to me that you should be both willing and able to answer. In the context of your question, these are not 'details' - they are fundamental issues. Vaguely saying that you get nervous when you see a message like 'undefined variable' is not satisfactory! If you can't post code that illustrates the problem, and you can't at least be precise about an error message - quote the wording, show a screenshot, *something *tangible - then you have not provided anything that anyone can usefully respond to. Which is unfortunate, because if I have understood your original code-related worry correctly, then it raises an issue that is of concern to all FTN95 users.

In my understanding, there is no question about one thing that should *not *happen to variables that are defined in modules USEd by a main program - they should never become undefined as long as the program is executing. Asking whether the standard allows a variable in a module to become undefined if that module is *not *used by the main program clouds the issue.

So ... I'll have one more go at obtaining a little sorely-needed precision, and I'll stop wasting my time if it is not forthcoming. Please allow me to test my understanding of your original *code-related *worry:

1. You are saying that you have, in the past, observed the following ... a variable call it X (that is defined in a module call it M, that is USEd by a main program call it P) whose value has become undefined when control has passed from M to P or to some other module N. Is this correct?

2. Your basis for saying this is:

1. that you received a run-time error message when you tried to compute with the value of X
2. that you noticed in the variables window of SDBG a line that said 'X= UNDEFINED'
3. that you noticed that the value of X changed (not under program control) after control passed from M
4. something else

Hopefully,

Andy

This usenet thread has a nice example: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0a54539ae0166e29

If that's the type of variable accessing KL is talking about, I agree to the postings on the thread that the variable is undefined even though current compilers 'do what you expect'. Nexgen compilers might not for whatever reason (code optimization etc.).

Hi Sebastian, The main program doesn't USE the module in question in that example - it calls routines that USE it. So it uses it, indirectly, but it doesn't USE it. If this is what Klaus has in mind (and I don't think it is), it is further illustration of the need for clarity 😉

The usenet thread is about the general case (scope of variables in a module), but maybe you can point out why you think moving the USE into the main program makes any difference in the argumentation.