forums.silverfrost.com

[KL]

7.8.2010

Paul,

First of all, please delete the previous post on this subject. Although this seems to be a very minor �problem�, I have seen it many times. I have now managed to condense the problem to a small (dummy) program named Test: When I compile the program Test with the options /List and /Dump (see compall.txt), I find in the list Test.lis 7 Save attributes for local variables.

SAVE INTEGER(KIND=3) IFALLL(10)
SAVE INTEGER(KIND=3) M
SAVE INTEGER(KIND=3) MAX_I
SAVE INTEGER(KIND=3) MIN_I
SAVE REAL(KIND=1) DELTA_Z
SAVE REAL(KIND=1) X1
SAVE REAL(KIND=1) C3

I have used the latest FTN95 version 5.50 as you can see from the files *.lis.

Since there is nowhere any Save statement I wonder where the Save attributes come from. Is it just because the call of an internal subroutine is considered by FTN95 as a leave from the calling subroutine?

Best regards,

Klaus Lassmann

Compile.bat:

[KL]

Sorry, the file test.lis has been cut. Here it is:
[code:1:f8ecba09f3]Silverfrost FTN95/WIN32 Ver 5.50.0 Test.F95 Sun Aug 8 12:37:53 2010

Compiler Options in Effect:
CHECKMATE COLOUR DELETE_OBJ_ON_ERROR DUMP FULL_DEBUG LIST MINIMISE_REBUILD NO_QUIT
NON_STANDARD SINGLE_THREADED

0001 AT 0
0002 ! ############### AT 0
0003 Subroutine Test AT 0
0004 ! ############### AT 3a
0005 AT 3a
0006 Implicit None AT 3a
0007 AT 3a
0008 Real :: C3, x1, Delta_z AT 3a
0009 AT 3a
0010 Integer :: Min_i, Max_i, m AT 3a
0011 AT 3a
0012 Integer , Dimension (10) :: ifalll AT 3a
0013 AT 3a
0014 ! ------------------------------------------------------------------ AT 3a
0015 AT 3a
0016 m = 5 AT 3a
0017 ifalll = 1 AT 45
0018 AT 6f
0019 Min_i = Minval ( ifalll (1:m )) AT 6f
0020 Max_i = Maxval ( ifalll (1:m )) AT b8
0021 AT 101
0022 C3 = 0. AT 101
0023 AT 10c
0024 Call Test_01 AT 10c
0025 AT 11a
0026 x1 = Delta_z AT 11a
0027 AT 12e
0028 Write (*,*) x1, C3, Min_i, Max_i AT 12e


Dump of all variables in TEST

Local Variables
SAVE INTEGER(KIND=3) IFALLL(10) @ 0 (at line 15)
SAVE INTEGER(KIND=3) M @ 40 (at line 11)
SAVE INTEGER(KIND=3) MAX_I @ 44 (at line 11)
SAVE INTEGER(KIND=3) MIN_I @ 48 (at line 11)
SAVE REAL(KIND=1) DELTA_Z @ 52 (at line 9)
SAVE REAL(KIND=1) X1 @ 56 (at line 9)
SAVE REAL(KIND=1) C3 @ 60 (at line 9)

Total stack size: 40 bytes
Total static size: 76 bytes

[KL]

Would it not be better to apply any cut of a contribution already in the preview. Here, I could see my full contribution.

[JohnCampbell]

Klaus,

If you remove the CONTAINS code, then the SAVE attribute does not appear. As I have not used CONTAINS in this way I am not sure if SAVE should be implied. Where CONTAINS is used in a module definition, SAVE is implied.

John

[PaulLaidler]

The Fortran Standard does not appear to say that module variables automatically have the SAVE attribute but these variables are required to persist in the same way as SAVEd variables.

The fact that FTN95 appears to have set this attribute internally is not unreasonable given that this behaviour is required.

In a main program, SAVE can be applied to a variable but is redundant (the Standard says this). In the same way FTN95 allows you to use SAVE for a module veriable but it is also redundant in this context.

[PaulLaidler]

Ignore my comments above. For some reason I assumed that it was a MODULE. I will take a look at this and get back to you.

[PaulLaidler]

The SAVE attribute is added by the compiler when a routine CONTAINS other routines. This appears to provide a mechanism for avoiding problems that could arise due possible side effects when the contained routine is called.

The attribute may only be needed or convenient in very special circumstances but my inclination is to leave well alone.

[KL]

Paul,

I am certainly not an expert, but this argumentation sounds strange to me. In my opinion it should not be necessary to set the save attribute for all internal variables because calling an internal subroutine from subroutine A does not mean to leave subroutine A.

Klaus

[PaulLaidler]

I can log this as something to be investigated but are you sure that it is important?

For only a few variables, the fact that they are SAVEd is not a great problem. It just means the storage is fixed whilst the program runs.

[KL]

I cannot judge whether this item is important or not. However, from all what I have read about Fortran 90, especially concerning the more general rules and concepts, I had not expected such a behaviour.

You mentioned in one of your replies that this is a measure against very unlikely side-effects. But the contrary could also happen. If a programmer had forgotten in a subroutine containing an internal subroutine to give a local variable the necessary SAVE attribute, this program would run with FTN95. But would it also run with other compilers?

Please take my arguments as what they are: simple remarks. Since I know this particular property of FTN95, I can live very well with it.

Klaus

[JohnCampbell]

My interpretation of the Fortran Standard is that you can not assume that the variable has the SAVE attribute, if not specified, but there is no requirement of the compiler that it must not be saved. That is an efficiency of the compiler for memory shareing.
Again I might be wrong again on my recollection of the Standard !
By the way, is the Fortran 95 Standard still valid or is it superceded by a more recent version ?

John

[PaulLaidler]

The current Fortran Standard is 2003.
Fortran 95 is a subset of 2003 and so is still valid.
FTN95 is supported as conforming to Fortran 95.

[davidb]

[JohnCampbell]

davidb wrote: