SAVE compiler directive in 64-bit compiler?

Is the SAVE compiler option active for the 64-bit compiler?

I have a vintage Fortran program which seems to assume that local variables in subroutines keep their value between calls. It only works with FTN95 32-bit if I use the SAVE directive when compiling.

I have compiled a 64 bit version using the SAVE directive, but it fails in a subroutine. Without a debug option I can't really investigate why, but it occurred to me that perhaps SAVE was not implemented.

Try this with /SAVE on the FTN95 command line...

program test
integer i,winio@
call inc(0)
i=winio@('%bt[OK]')
call inc(1)
i=winio@('%bt[OK]')
call inc(2)
end test

subroutine inc(flag)
 integer step,flag
 if(flag == 0) then
   step = 0
   return
 endif  
 step = step+1
 if(step == flag)then
   print*, 'Looks good'
 else
   print*, '/SAVE not applied or not working'
 endif    
end subroutine  

This program fails in exactly the same way as my test64.f if I compile it as a windows application. It seems the write(*) statement is the problem

If I modify the code to omit the clearwin stuff and compile it with /save/64 as a console application, it works fine and confirms that /save is working with the 64 compilation.

Youcan only be sure if the test also fails when /SAVE is omtted.

My personal view is that /save should be banned !

I think the standard states (somewhere) that you can't assume that /save is the default and there is a SAVE keyword in Fortran when you need this, as well as data statements. This has been the case since F90 and possibly F77.

Anyway I wanted to find out what is the default, and I tested both FTN95 and gFortran. (I don't have access to ifort so I would be interested in seeing what the default is and what options there are for the equivalent of /SAVE and /RECURSIVE.)

The simple program I wrote to identify if local variables are dynamic is:

!save_test.f90
!  program to test save attribute
!
!  My understanding is that the defauly is dynamic allocation of all local variables on the stack
!  this program tests this by calling a routine and checking the accumulation
!
      integer*4 i, res_1, res_2
!
      do i = 1,5
        call sub_1 (i,res_1)
        call sub_2 (i,res_2)
        write (*,*) i, res_1, res_2
      end do
!
    end

    subroutine sub_1 ( i, res )
      integer i, res, acum
!
      if ( i==1 ) acum = 0
      acum = acum + 1
      res = acum
    end subroutine sub_1

    subroutine sub_2 ( i, res )
      integer i, res, acum
      save acum                 ! this can be omitted
!
      if ( i==1 ) acum = 1
      acum = acum + 1
      res = acum
    end subroutine sub_2

the batch file I used to do the tests are: date /T >save.tce time /T >>save.tce

echo ftn95 save_test /lgo >> save.tce
ftn95 save_test /lgo >> save.tce

echo ftn95 save_test /lgo /save >> save.tce
ftn95 save_test /lgo /save >> save.tce

echo ftn95 save_test /lgo /64 >> save.tce
ftn95 save_test /lgo /64 >> save.tce

echo ftn95 save_test /lgo /64 /save >> save.tce
ftn95 save_test /lgo /64 /save >> save.tce

del save_test.exe
echo gfortran save_test.f90 -o save_test.exe >> save.tce
gfortran save_test.f90 -o save_test.exe
save_test >> save.tce

del save_test.exe
echo gfortran save_test.f90 -o save_test.exe -O3 -mavx -ffast-math >> save.tce
gfortran save_test.f90 -o save_test.exe -O3 -mavx -ffast-math
save_test >> save.tce

del save_test.exe
echo gfortran save_test.f90 -o save_test.exe -fno-automatic >> save.tce
gfortran save_test.f90 -o save_test.exe -fno-automatic
save_test >> save.tce

del save_test.exe
echo gfortran save_test.f90 -o save_test.exe -frecursive >> save.tce
gfortran save_test.f90 -o save_test.exe -frecursive
save_test >> save.tce

notepad save.tce

The results are: Both FTN95 and gFortran default to dynamic allocation of local variables FTN95 Ver 8.00.0 works with both 32_bit and /64 The SAVE statement works with /64

I would welcome any other compiler results, or discussion that my test is flawed. (I have assumed the write will overwrite the stack for dynamic to fail or 'save acum' can be omitted for a better test.)

John

As far as I know, global SAVE has never been standard Fortran, but specific machines and compilers may well have acted as though it was. It has never been safe to assume that local variables kept their values between consecutive invocations of subprograms. I can vaguely recollect McCracken pointing this out a half-century ago in one of his books.