chau@xenon.arc.nasa.gov (Dung Chau) (02/15/91)
I am looking for a tool which scans FORTRAN source code and identifies
variables which should be saved.
This is a simple example of a FORTRAN source code that needs to scan
and insert a SAVE statement:
subroutine sub (val)
integer val, i
data i/10/
10 val = val * i
i = i -1
goto 10
return
end
When subroutine sub is called the second time the value of i may not be the
same. Therefore, it needs to have a SAVE statement to make i become static.dik@cwi.nl (Dik T. Winter) (02/15/91)
In article <1991Feb15.000230.18585@news.arc.nasa.gov> chau@xenon.arc.nasa.gov writes: > I am looking for a tool which scans FORTRAN source code and identifies > variables which should be saved. I do not think you need *that*. > > This is a simple example of a FORTRAN source code that needs to scan > and insert a SAVE statement: > subroutine sub (val) > integer val, i > data i/10/ > 10 val = val * i > i = i -1 > goto 10 > return > end > When subroutine sub is called the second time the value of i may not be the > same. I do not think the routine will be called a second time! :-) > Therefore, it needs to have a SAVE statement to make i become static. This conclusion is not valid. Changes to variables that are initialized through data statements are either on purpose, or not. In the second case you do not want an inclusion of a SAVE statement. What you want is a tool that signals all places where a variable becomes undefined (like I in your example on execution of the RETURN statement; if ever). I believe there are programs floating around that do that. The names 'FCHECK', 'TOOLPACK' appear to have some place in my memory. (Although I just mailed somebody about the non-portability of 'TOOLPACK', it is very useful if you can get it working.) -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
pmk@craycos.com (Peter Klausler) (02/16/91)
In article <1991Feb15.000230.18585@news.arc.nasa.gov> chau@xenon.arc.nasa.gov writes: >I am looking for a tool which scans FORTRAN source code and identifies >variables which should be saved. > >This is a simple example of a FORTRAN source code that needs to scan >and insert a SAVE statement: > > subroutine sub (val) > integer val, i > data i/10/ > > 10 val = val * i > i = i -1 > goto 10 > return > end > >When subroutine sub is called the second time the value of i may not be the >same. Therefore, it needs to have a SAVE statement to make i become static. Variables that are initially defined with a DATA statement are static, and don't need a SAVE statement.
jlg@lanl.gov (Jim Giles) (02/16/91)
From article <1991Feb15.172635.17261@craycos.com>, by pmk@craycos.com (Peter Klausler): > [...] > Variables that are initially defined with a DATA statement are static, and > don't need a SAVE statement. No. ANSI X3.9-1978, page B-5, lines 7-11: Initially defined entities in a subprogram may become undefined at the execution of a RETURN or END statement if they are assigned any value, including their initial value, during the execution of the the executable program (see 8.9 and 15.8.4). And on page 15-15, lines 1-11: 15.8.4 Definition Status. Execution of a RETURN statement (or END statement) within a subprogram causes all entities within the subprogram to become undefined, except for the following: [...] (3) Initially defined entities that have neither been redefined or become undefined. [...] The purpose appears to be to allow (at least) the following interpretations of initialized (but unSAVEd - PAGAN? :-) variables: 1) On each entry, the value is again initialized according to the DATA statement; 2) On each entry (except the first), the value is retained from the previous instantiation (as if it had been SAVEd); 3) on each entry (except the first), the value is completely unpredictable (just like any other unSAVEd variable). J. Giles
wsb@boise.Eng.Sun.COM (Walt Brainerd) (02/16/91)
In article <1991Feb15.172635.17261@craycos.com>, pmk@craycos.com (Peter Klausler) writes: > In article <1991Feb15.000230.18585@news.arc.nasa.gov> chau@xenon.arc.nasa.gov writes: > >I am looking for a tool which scans FORTRAN source code and identifies > >variables which should be saved. > > > >This is a simple example of a FORTRAN source code that needs to scan > >and insert a SAVE statement: > > > > subroutine sub (val) > > integer val, i > > data i/10/ > > > > 10 val = val * i > > i = i -1 > > goto 10 > > return > > end > > > >When subroutine sub is called the second time the value of i may not be the > >same. Therefore, it needs to have a SAVE statement to make i become static. > > Variables that are initially defined with a DATA statement are static, and > don't need a SAVE statement. This is not correct, in general, though it may be true for some implementations. The rules state (17-4, 45-53) that "The execution of a RETURN statement or an END statement within a subprogram causes all entities within the subprogram to become undefined except for the following: . . . (b) Initially defined entities that have netiher been redefined nor become undefined . . ." In the example, i gets redefined, so its value upon reentry is up for grabs. This was done purposely to allow implementations to either save the old value or reinitialize upon reentry. Thus the programmer must use a SAVE statement to be portable if that is what is desired. -- Walt Brainerd Sun Microsystems, Inc. wsb@eng.sun.com MS MTV 5-40 Mountain View, CA 94043 415/336-5991