Porting old F77 to Absoft Compiler

[shaike]

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]

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]

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]

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]

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]

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]

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.