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 compiler directive in 64-bit compiler?

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
ljfarrugia



Joined: 06 Jun 2016
Posts: 35

PostPosted: Thu Jun 09, 2016 5:24 pm    Post subject: SAVE compiler directive in 64-bit compiler? Reply with quote

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


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

PostPosted: Fri Jun 10, 2016 7:45 am    Post subject: Reply with quote

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

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



Joined: 06 Jun 2016
Posts: 35

PostPosted: Fri Jun 10, 2016 5:02 pm    Post subject: Reply with quote

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


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

PostPosted: Fri Jun 10, 2016 6:58 pm    Post subject: Reply with quote

Youcan only be sure if the test also fails when /SAVE is omtted.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sat Jun 11, 2016 9:45 am    Post subject: Reply with quote

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



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Sun Jun 12, 2016 10:33 am    Post subject: Reply with quote

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.
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 -> 64-bit All times are GMT + 1 Hour
Page 1 of 1

 
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