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 Previous  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 Jan 05, 2011 12:07 pm    Post subject: Reply with quote

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.

K. Lassmann

PS. I regret that I cannot react to each contribution. In almost all cases my knowledge about compiler details is insufficient to comment.
Back to top
View user's profile Send private message
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Wed Jan 05, 2011 2:51 pm    Post subject: Re: Reply with quote

KL wrote:
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:
a) that you received a run-time error message when you tried to compute with the value of X
b) that you noticed in the variables window of SDBG a line that said "X= UNDEFINED"
c) that you noticed that the value of X changed (not under program control) after control passed from M
d) something else

Hopefully,

Andy
Back to top
View user's profile Send private message Send e-mail
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Wed Jan 05, 2011 3:19 pm    Post subject: Reply with quote

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



Joined: 11 Apr 2005
Posts: 371

PostPosted: Wed Jan 05, 2011 3:38 pm    Post subject: Reply with quote

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



Joined: 20 Feb 2008
Posts: 177

PostPosted: Wed Jan 05, 2011 4:50 pm    Post subject: Reply with quote

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



Joined: 11 Apr 2005
Posts: 371

PostPosted: Wed Jan 05, 2011 5:58 pm    Post subject: Reply with quote

OK, fair question Laughing

Because - like Klaus, as far as I can tell - I am under the impression that any variable, simply declared in a module, is only required to retain its value, per the standard and without taking further declarative steps, in other program units which USE that module.

In other words, when a module M passes control to another program unit N, X is only required to retain its value if N USEs M. If, therefore, N is the main program, X is required to retain its value throughout execution, wherever control may pass to in the meantime.

(Technical FORTRAN meaning of USE, not shouting, in the above).

I believe that Klaus believes the same thing, and claims on occasion to have observed this requirement being violated by FTN95.

I acknowledge that real compilers may choose not to exercize the freedom to throw variable values away in this fashion (what others are terming "behaving as one would expect"), but I was under the impression that they were at liberty to. I do not believe, however that this is germane to what is troubling Klaus.

If he is correct in what he claims on occasion to have observed, then either his (and my) understanding of the requirement is incorrect, or FTN95 is not implementing the requirement completely correctly.

I believe he is seeking adjudication one way or the other.
Back to top
View user's profile Send private message Send e-mail
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Wed Jan 05, 2011 7:58 pm    Post subject: Reply with quote

Quote:
If, therefore, N is the main program, X is required to retain its value throughout execution, wherever control may pass to in the meantime.

I'm not very familiar with the actual Fortran standards publications, and can't find anything in the docs that supports your claim (it sounds fine though, and may be how current compilers work, but if it's not hard-written somewhere you can't rely on it and thus have to use the SAVE attribute to write correct code if the value has to be retained).
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Jan 06, 2011 12:52 am    Post subject: Reply with quote

In the latest version of the Fortran 95 standard I know of : "J3/97-007R2 - October 21, 1997 12:28 pm" which I found from jjgermis's link above; in Section 14.7.6 "Events that cause variables to become undefined" on Page 290, point 3 discusses how Modules can remain defined after a return statement. There is always ambiguity about what MUST happen in other cases!
We must differentiate between USE and scope of a module in this discussion, as if routines A then B are called from the Main program and the module is only defined in A and B, then the scope of the module ceases on return from A, potentially rendering it undefined on entry to B. Why provide for this potential !! I have many static libraries which do this, and work.
My problem with this approach is it denies the basic concept of what a COMMON or MODULE is, which is a storage area for variables which has global access.
Causing variables in a Module to become undefined does not appear sensible to me. Indeed no "compiler" I have used implements this approach, although it is more an attribute of the linker in how it handles the memory allocation for Modules.
Making local variables have dynamic memory allocation has some merit, as it minimises the memory usage of many routines and allows for recursion, however making global variable structures dynamic appears to have much less, even no merit.
My main problem in this post is I do not agree with the standard where it potentially allows common or modules to become undefined. As I said before, this is managed in the linker and the only place where I saw this implemented was in an overlay linker in a DOS 640k environment.
Is Klaus trying to do a standard conforming review of the FTN95 compiler or is the solution simply to put a USE statement in the main program ? My understanding of FTN95/Slink is that COMMON and MODULES do not become undefined, except of for allocatable arrays in modules that are in a DEALLOCATE statement. I have recently used this construct to prepare for 64-bit array allocation and have had no problems of unexpected undefined status.
I recall this discussion in the Lahey email forum about 5 years ago. I'm not sure where it ended.

One thing is for sure, we are not going to change the 95 standard. Klaus, do you know if the description of this problem has changed in the 03 or 08 standards ?

John
Back to top
View user's profile Send private message
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Thu Jan 06, 2011 2:22 am    Post subject: Reply with quote

Quote:
I have many static libraries which do this, and work.

"It works" and "It's standard compliant and thus works" are completely different things, the first case may work since a long time but then due to some circumstances (because the standard doesn't require it to be like that) it may change. For example to utilize additional optimizations or whatever.


Quote:
how Modules can remain defined after a return statement. There is always ambiguity about what MUST happen in other cases!

If it's not explicitly defined, anything can happen. This has some strange effects especially with C/C++ compilers (under/overflowing arithmetics, out of array access, ...) but the most simple case is accessing an uninitialized variable: there is absolutely no guarantee about what value it contains, behaviour is undefined (so any a=b with b undefined may put 0 into a, may put 7 into a or may even execute pacman and the last case is *not* a joke).


Quote:
Is Klaus trying to do a standard conforming review of the FTN95 compiler

I think his main point is that in almost all cases the compiler does "what most people expect" for his problematic code, but some cases turned up where it was different, as he stated the SAVE attribute was required.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Jan 06, 2011 6:51 am    Post subject: Reply with quote

Quote:
but some cases turned up where it was different, as he stated the SAVE attribute was required.

As FTN95 retains Modules and Common as static allocation (except for Allocatable arrays), I would be surprised if applying SAVE to a module would be the reason for the change. Can Klaus confirm if this took place ?

I can report I have not identified the problem that Klaus initially suggested, as in my recent use of modules, I don't use SAVE on any modules and have not identified any loss of variable values. I have converted some of my libraries to use modules with no problems. These would fail the scope test. My Allocatable arrays in modules also retain their value until they are de-allocated, without any impact on other variables in the module, although this module is defined in the main procedure.

John
Back to top
View user's profile Send private message
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Thu Jan 06, 2011 2:32 pm    Post subject: Reply with quote

I restrict myself to important aspects of the discussion only.

I am sorry, that I cannot post an example code that illustrates the problem. The code is much too big for the forum. I have tried to condense it to a suitable size, but failed. In view of the complexity of the code I have never expected that somebody -even if he is author of a book- can tell me from the debugger output where the error is. (I can read the debugger message myself, see also below). Instead I have posted this problem clearly as a question (“My question is whether somebody has made similar experiences?” Nothing more).

The discussion shows that there are quite different views on this subject. I read for instance that there might be some freedom for compiler developers to implement such features with –may be- compiler dependent properties. Hard to believe for a language with the goal to increase portability. However, such implementations are completely unknown to me. I work for good reasons for many, many years with Salford/Silverfrost compilers only.

Putting all this together, I conclude, that Silverfrost developers can best clarify the question and probably nobody else. I understood Paul Laidler that he will have a look to the item and I will wait for his answer.

I have never stated that I can exclude a difficult to find error in the code, which I have not written myself. The code uses 4 huge input data sets from an even bigger code (up to 100 MB direct access data sets) and of course I will check these data sets for consistency as well as the code itself. And I will discuss the problem with one of the authors of the code probably by the end of January.

Therefore I repeat what I have said already: “I cannot contribute anything more to the discussion”. A last remark: This thread is not suffering from insufficient clarity of definition of terms but –much simpler- from a mixture of a general discussion about a Fortran rule, may be its implementation and from a code that is not available to everybody.

KL

PS

For AS: I have applied the compiler options /CHECKMATE and /Full_Debug. The error message is the normal error message for undefined variables from sdbg. The definition “undefined not to be relied upon” is unknown to me and I have never seen it in any Fortran book. May be that this concept is discussed in newer books or it refers to specific compiler implementations.
Back to top
View user's profile Send private message
Sebastian



Joined: 20 Feb 2008
Posts: 177

PostPosted: Thu Jan 06, 2011 2:55 pm    Post subject: Reply with quote

Quote:
definition “undefined not to be relied upon” is unknown to me

This is a pretty well-defined situation, if something is not explicitly written in the standard, anything can happen.
Read for example http://en.wikipedia.org/wiki/Undefined_behavior
or an article with really nice examples (especially the security related ones that are the essence of recent GCC complications) at
http://blog.regehr.org/archives/213

So if module variable persistence is not guaranteed under the usual use scenario, it's worth knowing that since it is an assumption I'm used to in everyday sources.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Jan 06, 2011 3:47 pm    Post subject: Reply with quote

Now that I have come to look at this more carefully I find that this thread raises a different question to your earlier thread started on 6 August.

In the first thread you seemed to be saying that the SAVE attribute was added by the compiler when not explicitly requested in your program.

Now you seem to say that the SAVE attribute, which ought to be added by the compiler, is not being added and you have to add it explicitly in your program.

I have tested this using the following code and can find no problem here.
Unless you can supply a program that fails, there is little or nothing I can do to investigate the problem.

With kind regards

Paul

Code:
module m1
integer,allocatable::k1(:)
end

subroutine s1()
use m1
allocate(k1(10))
end

subroutine s2()
use m1
k1 = 10
end

program p1
use m1
call s1()
call s2()
end
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Jan 06, 2011 10:37 pm    Post subject: Reply with quote

Klaus,

You say
Quote:
The error message is the normal error message for undefined variables from sdbg.

As you are using SDBG, are you able to look at the value of all variables in the module and see if they are all undefined, or if it is only a few it may be some other problem.

John
Back to top
View user's profile Send private message
KL



Joined: 16 Nov 2009
Posts: 144

PostPosted: Fri Jan 07, 2011 3:30 pm    Post subject: Reply with quote

Paul,

I would like to thank you for the clarification, which is certainly not only based on the example given.

I have made some further tests myself and it looks as if all variables in a module automatically get the SAVE attribute (or are treated as static variables). The following code gives an example:

Code:

winapp

module mod1
 integer , Dimension (:), Allocatable :: intvar
end module mod1
 
program prog1
! use mod1
    call sub1
    call sub2
end program prog1

subroutine sub1
  use mod1
  Allocate (intvar ( 1:100000))
            intvar = 1 ! define intvar (1:100000)
  write (*,*) sum ( intvar ) * 1
end subroutine sub1

subroutine sub2
  use mod1
  Implicit None
  write (*,*) sum ( intvar ) * 2
end subroutine sub2


May be that the statement of Metcalf et al., fortran 95/2003 explained (see begin of the thread) is no longer valid or I have misunderstood it.

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