Bad code generated with Assigned GOTO and /save

A large program (http://plato.asu.edu/ftp/other_software/dqed.f.gz), dating back to the 1980-s, contains Assigned GOTO statements and also requires the /save compiler option. The following tiny program reproduces the bug that I encountered when I used the 32-bit FTN95 8.10 on the DQED program.

      program AsgGoto
      implicit none
      integer nv
      nv = 8
      call dqed(nv)
      print *,'Returned to main'
      end
!
      subroutine dqed(nvars)
      implicit none
      integer nvars,igk
      integer, save :: iflag = 0
      assign 40 to igk
      if (iflag.eq.0) then
          if (nvars.le.0) then
              assign 50 to igk
          end if
      end if
      goto igk
   40 iflag=iflag+1
      return
   50 stop 'xyz'
      end

The two ASSIGN statements result in code similar to

mov dword ptr [00000024], 004010D0

instead of

mov dword ptr [00400024], 004010D0

As a result of this, the program aborts with an illegal access to address 00000024.

The test program should function the same way whether /save is used or not, but the bug occurs only when /save is used.

The 64-bit compiler does not have this problem.

Thank you. I have made a note that this needs fixing.

This failure has now been fixed for the next release of FTN95.

Truly, Mecej4, you never cease to surprise.

May I remind you of the adage *'He who sups with the Devil should use a long spoon' *? It's particularly apt when sampling various bits of Fortran from the Internet.

ASSIGNED GOTOs may well be still supported by FTN95, even though they have been marked for deletion (of which I disapprove, naturally), and usually, there are far better ways of doing that particular job.

But worse still is the need for SAVE. This has been the mark of someone who ignores the rules, as written down on tablets of stone by the Holy Backus in the Beginning, and is therefore not to be trusted.

Eddie