forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Save attribute for module variables
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Wed Dec 29, 2010 9:04 am    Post subject: Save attribute for module variables Reply with quote

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.
Back to top
View user's profile Send private message
jjgermis



Joined: 21 Jun 2006
Posts: 404
Location: Nürnberg, Germany

PostPosted: Wed Dec 29, 2010 7:57 pm    Post subject: Reply with quote

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?

Code:
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
Back to top
View user's profile Send private message
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Thu Dec 30, 2010 10:02 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Dec 30, 2010 10:26 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Thu Dec 30, 2010 10:51 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Dec 30, 2010 10:56 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
jjgermis



Joined: 21 Jun 2006
Posts: 404
Location: Nürnberg, Germany

PostPosted: Thu Dec 30, 2010 11:05 am    Post subject: Reply with quote

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.

Code:
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
Back to top
View user's profile Send private message
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Thu Dec 30, 2010 1:02 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
jjgermis



Joined: 21 Jun 2006
Posts: 404
Location: Nürnberg, Germany

PostPosted: Thu Dec 30, 2010 1:32 pm    Post subject: Reply with quote

Perhaps for other readers: The Fortran standards can be view at
http://www.fortran.com/
-> Information
-> standard documents.
Back to top
View user's profile Send private message
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Thu Dec 30, 2010 2:48 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
JohnHorspool



Joined: 26 Sep 2005
Posts: 270
Location: Gloucestershire UK

PostPosted: Thu Dec 30, 2010 5:08 pm    Post subject: Reply with quote

jjgermis,

Very interesting link, thankyou!

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

John
Back to top
View user's profile Send private message Visit poster's website
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Fri Dec 31, 2010 12:40 pm    Post subject: Re: Reply with quote

JohnCampbell wrote:
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 Smile 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 Wink . 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?
Back to top
View user's profile Send private message Send e-mail
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sun Jan 02, 2011 11:15 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Mon Jan 03, 2011 8:41 am    Post subject: Reply with quote

Quote:
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).
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Jan 03, 2011 1:01 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group