Internal compiler error

FTN95 7.1 on Windows 8.1 X64 runs into an internal error related to an FPU underflow exception when run on the code below, if before running the compiler the environment variable SALFENVAR is set equal to MASK_UNDERFLOW. The code is a severely stripped down version of DanRRight's code in a recent thread https://forums.silverfrost.com/Forum/Topic/2668 . The stripped down code will probably look silly, but the compiler is very sensitive to small changes to the code. In fact, rearranging the source code to interchange the order of the subroutines in the file (such that the subroutine with the comment 'UNDERFLOW' appears second) makes the internal error go away.

    Subroutine sub1(en, zn, k_el)
      Real *8 en

      Call die(aip, zn, en, k_el)
      aiz = ez0(i, k_el)
      If (aiz<=0D0) aiz = 1.D-100 ! <<<<===== UNDERFLOW!
      Return
    End Subroutine sub1

    Subroutine sub2(zs, zn, cnt, zsr)
      Dimension p(99)
      Real *8 cnt(99)
      Real *8 zsr

      iznp1 = zn + 1.1

      Do i = 1, iznp1
        cnt(i) = 0.
      End Do

      izs = zs
      izmin = izs - 4
      izmax = izs + 6
      p(izmin) = 1.
      Do i = izmin, izmax
        izmax = i
        Exit
      End Do

      cnt(izmin:izmax+1) = p(izmin:izmax+1)
      zsr = 0.

      Do i = izmin, izmax + 1
        zsr = zsr + float(i-1)*cnt(i)
      End Do

      Return
    End Subroutine sub2

Thanks for this. I have logged it for investigation.

At first sight there are two subroutines here that call other undefined subroutines, no main program. Did you intend that we go back to Dan's code in order to demonstrate this failure?

Thanks for looking at this, Paul.

This test code exposes a compiler error. It is not intended to be run or do anything useful. I obtained it by trimming Dan's rather long and complex example, which also did not contain a main program.

Normally, one does not expect compilation to be affected by compiler-specific environment variables that are documented for their effects on a running program that was compiled earlier. Here, there is an easy work around, but it is still an error that the compiler gets affected in an unexpected and undocumented way by the user's having previously set an environment variable to control the running of a user program.

Thank you for this. If anyone can provide a small working program that illustrates the issue then we can progress from there.

Perhaps I did not stress this point enough: this report is not about an error that is encountered when running a user program. The faulting program is the compiler itself -- FTN95.EXE plus, possibly, its support DLLs.

Other vendors, such as Intel, would call such an error an Internal Compiler Error (ICE). In the presence of such an error, the compiler crashes, the compilation fails, so producing a working user program is impossible.

Thanks. There is no confusion. No doubt there is an error in the FTN95 compiler and/or in salflibs.dll. We need a working program in order to trace the fault. The direct way to work is to step through FTN95 or salflibc.dll as they compile or run the given program.

I think Paul is wrong here.

Here is a working version of the program (slightly changed)

From the command prompt set SALFENVAR=MASK_UNDERFLOW FTN95 code.f90 /LGO

    ! code.f90
    Subroutine sub2(zs, zn, cnt, zsr)
      Dimension p(99)
      Real *8 cnt(99)
      Real *8 zsr

      iznp1 = zn + 1.1

      Do i = 1, iznp1
        cnt(i) = 0.
      End Do

      izs = zs
      izmin = izs - 4
      izmax = izs + 6
      p(izmin) = 1.
      Do i = izmin, izmax
        izmax = i
        Exit
      End Do

      cnt(izmin:izmax+1) = p(izmin:izmax+1)
      zsr = 0.

      Do i = izmin, izmax + 1
        zsr = zsr + float(i-1)*cnt(i)
      End Do

      Return
    End Subroutine sub2 

    Subroutine sub1
      real aiz
      aiz = 0.0
      If (aiz<=0D0) aiz = 1.D-100 ! <<<<===== UNDERFLOW!
      print *, aiz
    End Subroutine sub1

    program anon
       call sub1
    end program

Now swap order of sub1 and sub2 and you get an error during compilation.

So it does.

Thank you for the modified code. Hopefully this will be sufficient.

This bug has been fixed for the next release. In the short term the environment variable SALFENVAR should not be used for mask_underflow. Instead call mask_underflow@ at the start of your program. This has the same effect at run time.

A word of explanation...

FTN95.exe was failing because of a FPE when calculating statistics (e.g. the time taken to compile a program). This occurred in a call to DCLOCK@ and also in the calculation that followed.

The fix in the compiler is to undo the effect of this environment variable setting and (in salflibc.dll) to modify DCLOCK@ so that it is more robust.

Thanks for the quick response, and I appreciate being given the explanation.