Incorrect results for sum(vector expression)

FTN95 8.30.279 produces incorrect results or aborts with floating point errors for the following correct code. The value on line-21 was chosen to make the result to be exactly 0.

program tfu
implicit none
integer, parameter :: double=kind(0.d0), NX=16
real(double) :: x(NX),F
integer :: i,n
!
n = NX
Do i = 1, n, 4
   x(i)   = 1.0D0
   x(i+1) = 3.0D0
   x(i+2) =-1.0D0
   x(i+3) = 0.0D0
End Do

print 10,x

F = sum (( x(:n-3:2) + 1.0D1*x(2:n-2:2))**2     &
         + 5.0D0*(x(3:n-1:2) - x(4:n:2))**2     &
         + (x(2:n-2:2) - 2.0D0*x(3:n-1:2))**4   &
         + 1.0D1*(x(:n-3:2) - x(4:n:2))**4)     &
         - 14195d0

print 20,F

10 format ('X = [',16F5.1,']')
20 format('F = ',F10.1,', expected value = 0.0')

End Program

The results from various runs:

OPTION         RESULT

/check           -11040.0
/checkmate       -11040.0
 - default -     Floating point divide by zero
/opt             Floating point divide by zero

/64 /check       -11040.0
/64               *** AMD backend failure
/64 /opt         -16929.0

mecej4,

What an example !! Where did you get this code from ? What would happen if N is not a multiple of 4 ? If this is an example of Fortran on WWW they didn't learn Fortran where I did.

I thought I would confirm your results. I am using FTN95 Ver 8.20.0

I also adapted your example to try and understand the implied loops in the array section. program tfu implicit none integer, parameter :: double=kind(0.d0), NX=16 real(double) :: x(NX),F, Acum integer :: i,n,k ! n = NX Do i = 1, n, 4 x(i) = 1.0D0 x(i+1) = 3.0D0 x(i+2) =-1.0D0 x(i+3) = 0.0D0 End Do

print 10,x 

  acum = 0
  do k = 0,n-4,2
     acum = acum                                    &
          +       ( x(k+1) + 1.0D1*x(k+2) )**2      & 
          + 5.0D0*( x(k+3) -       x(k+4) )**2      & 
          +       ( x(k+2) - 2.0D0*x(k+3) )**4      & 
          + 1.0D1*( x(k+1) -       x(k+4) )**4  
  end do
  acum = acum - 14195d0 
print 30,acum 

F = sum (( x(:n-3:2) + 1.0D1*x(2:n-2:2))**2     & 
         + 5.0D0*(x(3:n-1:2) - x(4:n:2))**2     & 
         + (x(2:n-2:2) - 2.0D0*x(3:n-1:2))**4   & 
         + 1.0D1*(x(:n-3:2) - x(4:n:2))**4)     & 
         - 14195d0 

print 20,F 

10 format ('X = [',16F5.1,']') 
20 format ('F = ',F10.1,', expected value = 0.0') 
30 format ('A = ',F10.1,', expected value = 0.0') 

End Program

I can confirm that I got the same results as you report. (acum = 0 in all cases)

In the past, FTN95 has demonstrated errors when the available registers are not sufficient to convert a single statement. This looks like a likely possibility.

John

Thank you for the bug report. I have logged this for investigation.

John: Thanks for testing, and for the F77 version.

Quoted from JohnCampbell

Where did you get this code from ? What would happen if N is not a multiple of 4 ?

During the last few months, I replaced an older laptop with a new desktop PC, and thought of exploiting its power to uncover bugs that I suspected to be present in FTN95's code generation and optimisation, particularly for F95 language features. I wanted to use medium size (< 100K lines) packages that came with test examples and known results.

This particular example code came into being as follows. I took the PNED code from http://www.cs.cas.cz/luksan/subroutines.html and translated the code from F77 to F90 using VAST79. For some of the test problems, the F77 and F90 versions did not give the same results. I pruned the F90 code to obtain the example code above (TNEDU test, case NEXT = 3). The PNED example had N=1000; I reduced N to 16 to enable checking with pencil and paper, and ended up with the example code.

VAST79 produced code with syntax errors in this case, but I was able to correct those with the help of FTN95.

Yes, N has to be a multiple of 4; the example code serves only to demonstrate the compiler errors.

I found it amusing that in a couple of runs FTN95 aborted with FP divide by zero, when there is no apparent need to do any division at all.

Incidentally, FTN95 7.20 did better at compiling the example than 8.30 did.

Thanks, John Silver. Guided by your feedback, I constructed a shorter example, and this exposes a couple of different bugs in the compiler.

program tfu0
implicit none
integer, parameter :: NX = 16
real :: x(NX),f,c,d
integer :: i, n = NX

x = [(1.0, 3.0, -1.0, 0.0, i=1,n/4)]

print 10,x

c = sum ((x(2:n-2:2) - 2.0*x(3:n-1:2))**4)
d = sum ((x(:n-3:2) - x(4:n:2))**4)
F = c + 10.0*d - 10268.0

print 20,c,d,F

10 format ('X = [',16F5.1,']')
20 format('c,d = ',2F10.1,'  (expected: 2548.0, 772.0)',/'  F = ', &
          F10.1,', expected value = 0.0')

End Program tfu0

The results from FTN95 V 8.30.279:

-default-      FP div by zero
/debug         FP div by zero,  line-12
/check         Internal compiler error
/checkmate     Access violation, line-12


/64            Incorrect results for c (1500), d (-576), F (-14528)
/64 /debug                  -ditto-
/64 /check     Incorrect results for c (600), d (0), F (-9668)
/64 /checkmate              -ditto-

With the older V 7.20, this program gives correct results except when /opt is chosen.

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