Optimization bug with CYCLE

Hi,

The program below gives different results with /OPTIMISE but shouldn't. I am running FTN95 5.21. This is a very serious bug that will break a lot of code.

      PROGRAM CYCLE_BUG

      ! Demonstrates FTN95 5.21.0 bug with CYCLE under optimization
      ! Building with  ftn95 CYCLE_BUG.f90 /LINK            gives correct results
      ! Building with  ftn95 /OPTIMISE CYCLE_BUG.f90 /LINK  gives incorrect results

      IMPLICIT NONE

      INTEGER, PARAMETER :: N = 2
      INTEGER :: I, J
      CHARACTER(3) :: A(N) ! With a size of (1) or (2) the bug doesn't appear

      A(1) = '1'
      A(2) = '2'
      I_loop: DO I = 1, N
        DO J = 1, 5
          print *, J, ' ', I, ' ', A(I) ! A(I) always shows as A(1) with /OPTIMISE
          IF ( J == 2 ) CYCLE I_loop
        END DO
      END DO I_loop

      END PROGRAM

Thank you for reporting this bug. As a temporary work-around you can use /inhibit_opt 30.

Clearly a bug, and clearly deserving attention. Certainly a bug that could cause a lot of code written to 90 or 95 standards to misbehave. However, if one codes this in Fortran-77 (or earlier) style – with a GOTO – it works perfectly.

On reading the helpfile (FTN95.chm), I saw that the presence of GOTO inhibits optimisation. Is it therefore the case that the code with a GOTO is simply not optimised, which is why it works? With so few loop iterations, it is difficult to see the effect on runtime of the optimiser. I presume that it is significant.

I also experimented with doing something with I, as apart from printing the values, I and J aren’t used. If I put K=I above the inner loop, and then printed A(K) not A(I), the optimised code also worked.

The machinations of the optimiser are a mystery.

As far as using /INHIBIT_OPT30 goes, where does one find a list of optimisations and their numbers? This option is undocumented – are there any other useful facilities of this type? How one would decide which optimisations to “inhibit” is a difficult question. Is there not a case to be made for dividing/grouping optimisations into classes, such as “completely safe”, “probably safe”, “possibly unsafe” and permitting the programmer to select which level to employ? I recollect that MS Fortran did something of the sort.

Eddie

FTN95 carries out significant optimisation even when /OPT is not used. Many of the extra optimisations are concerned with reducing the number of register transfers at machine code level. You should always do some test runs and timings with and without /OPT before using /OPT for your permanent release.

/INHIBIT_OPT is not intended for general use and so remains undocumented.

We recognise this as a significant bug and plan to fix it as soon as possible.

Paul,

I wasn't suggesting that INHIBIT_OPT went on general release!

It is clear from your answer that (internally at least) optimisations are seen in two categories: those that are safe to unleash on the run-of-the-mill user, and those that need to be deliberately invoked (and therefore must implicitly contain some risk of unintended side effects, else why not include them in the former category). It therefore isn't surprising to me that there are cases where optimisation doesn't work, but this is a particularly simple case that one would expect to.

You didn't answer as to whether the GOTO equivalent works because the optimisation isn't applied, or whether it is applied and it works with GOTO and not CYCLE.

Eddie