gfxgfx
 
Please login or register.

Login with username, password and session length
 
gfx gfx
gfx
1617 Posts in 535 Topics by 779 Members - Latest Member: rhoronjeff@comcast.net December 02, 2022, 10:24:07 PM
*
gfx* Home | Help | Search | Login | Register | gfx
gfx
Absoft User Forum  |  Support  |  Windows  |  Porting old F77 to Absoft Compiler
gfx
gfxgfx
 

Author Topic: Porting old F77 to Absoft Compiler  (Read 486 times)

shaike

  • Newbie
  • *
  • Posts: 4
Porting old F77 to Absoft Compiler
« on: August 27, 2022, 04:00:47 AM »
I sense (not 100% sure) that the following code is NOT working:

     subroutine OPT(......,kk)
     Integer switch
     if (kk.GE.0) GO TO SWITCH , (140,310,390,430)
     ....

     ASSIGN Label to SWITCH
     ....

where Label is  one of 140, 310, 390, 430

And kk  has an initial value of kk=-1 in the calling subroutine. It then takes other values on execution of Subroutine OPT.
The value for Switch is by the ASSIGN statement in subroutine OPT (..)
Is is possible that the ASSIGN or GO TO SWITCH , (140,310,390,430) are obsolete? If so, is there an alternate form?


mecej4

  • Jr. Member
  • **
  • Posts: 76
Re: Porting old F77 to Absoft Compiler
« Reply #1 on: August 29, 2022, 08:22:58 AM »
The assigned GOTO is a deleted feature of modern Fortran. However, compilers continue to accept and compile code containing assigned GOTOs and, as long as the codes obey the rules that assigned GOTOs have to obey, the code should continue to work.


There is not enough detail in the code fragment that you showed to provide a definite answer to your question, but some comments may be made. If the subroutine is called with a value of kk >= 0, the program is non-conforming since SWITCH is undefined at the point of entry. Even though you show an ASSIGN label to SWITCH statement near the end, that will not prevent SWITCH from becoming undefined when the subroutine is exited.


Also, note that assigning a label to SWITCH makes SWITCH undefined as an integer variable, and that assigning an integer value to SWITCH would similarly make SWITCH undefined as a label. This "dual personality" is one of the reasons why assigned GOTOs were deleted from the language.

shaike

  • Newbie
  • *
  • Posts: 4
Re: Porting old F77 to Absoft Compiler
« Reply #2 on: September 04, 2022, 01:53:16 PM »
Thanks a lot for the informative answer! I bypassed the problem by replacing the ASSIGNED GOTO with the following code:
       IF (switch.EQ.140) THEN
          GO TO 140
         ELSE IF (switch.EQ.310) THEN
           GO TO 310
           ELSE IF (switch.EQ.390) THEN
          GO TO 390
         ELSE IF (switch.EQ.430) THEN
           GO TO 430
        ENDIF     

SWITCH is now an integer and I preserve its value by using a new COMMON block.
I then encountered a new issue which may be related to the original ASSIGN question:
A scalar array is sequentially given a value for each element on each subroutine call. Nevertheless, the values are lost at the end of the process, i.e. the values of the array elements are not preserved.
Is this a FORTRAN mistake or should I change parameters in the Absoft Compiler PROJECT OPTIONS?

mecej4

  • Jr. Member
  • **
  • Posts: 76
Re: Porting old F77 to Absoft Compiler
« Reply #3 on: September 05, 2022, 02:33:00 PM »
A scalar array is sequentially given a value for each element on each subroutine call. Nevertheless, the values are lost at the end of the process, i.e. the values of the array elements are not preserved.
Is this a FORTRAN mistake or should I change parameters in the Absoft Compiler PROJECT OPTIONS?
What do you mean by "scalar array"?

If you want the value of a local variable in a subprogram to be preserved between calls, you have to give the variable the SAVE attribute when you declare it.

shaike

  • Newbie
  • *
  • Posts: 4
Re: Porting old F77 to Absoft Compiler
« Reply #4 on: September 06, 2022, 07:24:16 AM »
Thanks again for the support...

The local array is y(i). 'v' is calculated by the calling subroutine

subroutine opt (x, n, m, v, le, he, tol, kk)
dimension y(41)
SAVE y
  :
  :
i = i+1
y(i) = v

Upon each entry 'i' is incremented by one. The problem persists with and w/o the SAVE y.

forumadmin

  • Administrator
  • Sr. Member
  • *****
  • Posts: 333
Re: Porting old F77 to Absoft Compiler
« Reply #5 on: September 06, 2022, 08:21:35 PM »
If the index variable i is also expected to retain its value between calls, you need to add it to the SAVE list as well. You could also use the SAVE statement without a varible list to apply the SAVE attribute to every local variable in the routine.

As an alternative, the compiler provides a static storage option that can be used to emulate the behavior of older FORTRAN compilers without having to add SAVE statements. In AbsoftTools, you will find it in the Project Options dialog->FORTRAN page->Compatibility tab. It is located directly above the One Trip DO Loops option. If you are compiling from the command line, the static storage option is enabled with the -s flaq.




shaike

  • Newbie
  • *
  • Posts: 4
Re: Porting old F77 to Absoft Compiler
« Reply #6 on: September 07, 2022, 02:33:16 AM »
Eureka!
I added SAVE to the index i and the program works. However, currently the Array y(i) does not have a SAVE attribute and now the y-array values are preserved....
I appreciate the most valuable help. I hope that this forum stays alive after Absoft will close down Sep 30.

Absoft User Forum  |  Support  |  Windows  |  Porting old F77 to Absoft Compiler
 

gfxgfx
gfx gfx
Powered by MySQL Powered by PHP Valid XHTML 1.0! Valid CSS!