Faulty code generated with /opt /64

The expected output of this short program:

program bugchk
   implicit none
   integer, parameter :: N = 5
   integer :: i,m,m1
   integer :: ia(N+1), wn(N)

   ia   = (/ 1,  11,  21,  31,  41,  51 /)
!
   m1 = ia(1)
   do i = 1 , n
      m = m1
      m1 = ia(i+1)
      wn(i) = m1 - m        ! BAD CODE GENERATED FOR THIS
   end do
   print '(1x,A,5i4)','WN : ',wn

end program

is

 WN :   10  10  10  10  10

Compiling and running the program with FTN95 8.30.279 produces the correct output except when the /opt and /64 options are both specified, in which case the output is

 WN :    0   0   0   0   0

Examination of the /exp listing shows how the bug occurs (please see comments added to the relevant lines of the listing):

   0011         m = m1                                                                           AT 67
   0012         m1 = ia(i+1)                                                                     AT 67
   0013         wn(i) = m1 - m        ! BAD CODE GENERATED FOR THIS                              AT 67
   0014      end do                                                                              AT 67
   0015      print '(1x,A,5i4)','WN : ',wn                                                       AT 67
   0016                                                                                          AT 67
   0017   end program                                                                            AT 67
00000067(#1,51,17):      Loading variables and other into registers prior to loop
00000067(#1,52,17):      MOVSX_Q   R8,I
0000006c(#1,53,17):      MOVSX_Q   RDI,M
00000071(#1,54,17):      MOVSX_Q   RSI,M1
00000076(#43,14,10):      ALIGN16
00000080(#43,15,10):      N_3:
00000080(#50,16,11):      Removed instruction
00000080(#50,17,11):      MOV_Q     RDI,RSI         # m = m1
00000083(#110,18,12):      Removed instruction
00000083(#56,19,12):      MOVSX_Q   R14,IA[4*R8]    # IA(I+1)
00000088(#56,20,12):      MOV_Q     RSI,R14         # m1 = IA(I+1)
0000008b(#117,21,13):      SUB_Q     R14,RSI        # BUG HERE, should have been SUB_Q   R14, RDI

Thank you for this report. I have logged it as needing attention.

I have had a look at this program and the coding has indeed fooled the FTN95 Fortran loop optimiser. The optimisation is number 1 so a work-around is to use /opt with /inhibit_opt 1.

It turns out that in this case the programmer's optimising strategy makes the program run more slowly. It is in fact faster to simply write wn(i) = ia(i+1)-ia(i) (comparing the runtimes for the two approaches both without /opt).

I don't know how much work would be involved in making the optimiser cleverer in this context. The danger is that we end up suppressing optimisations that are valid.

Paul,

Surely the point is that an optimisation should produce (a) a change in execution speed, and at worst (b) changed roundoff, not wrong code. Those who use optimisation features in a compiler should know that sometimes, the changed execution speed is for the worse with particular constructs.

The example I am most familiar with is the removal of common subexpressions. If the compiler does that procedure relatively diligently, the programmer can still fool it, if, for example, a2 + b2 appears in one place, but b2 + a2 in another. In any case, setting c = a2 + b2 and using c instead may be better or worse, depending on how far ahead the optimiser can look, and whether or not it replaces exponentiation with repeated multiplication, for example, if c = aa + bb, or how registers are allocated. Just a guess, but probably not using the 8087 stack makes the third of these more difficult.

Those of us whose experience began long before optimisation via the compiler was a realistic possibility are often diligent in removing common subexpressions, particularly those with expensive functions. Whether or not it leads to adverse changes in execution time is far less important than the risk of producing wrong answers.

Eddie

Eddie

Yes one would naturally aim for correct code and this seems relatively straight forward for most things with common subexpressions as a particular example.

The situation for 'Fortran loops' is much more tricky and I am beginning to think that we need to make /opt 'safe' by removing things like 'Fortran loop' optimisation whilst making them available (in some other way) as a separate 'unsafe' option. For example we could have /opt (as the 'safe' option) and /optx with everything included (together with a health warning).

Correction:

The temporary 'fix' is to use /inhibit_opt 40.

It turns out that number 1 cuts out a whole raft of optimisations.

Quoted from PaulLaidler Correction:

The temporary 'fix' is to use /inhibit_opt 40.

It turns out that number 1 cuts out a whole raft of optimisations.

Thanks, Paul, that works!

Is the number specified after /inhibit_opt an ordinal number, or is it a bit-mask obtained by OR-ing individual bits that represent individual optimisations?

In either case, it would help to have a list of the meanings (of all or at least an important subset of) the various optimisation numbers/flags.

It is an ordinal number.

I am trying to get hold of a list.

Thank you!

The original bug reported on this thread has now been fixed for the next release of FTN95.