Incorrect evaluation of vector expressions

The bugs reported here are akin to those that I recently reported in the thread https://forums.silverfrost.com/Forum/Topic/3462 . Here, I have a drastically simplified and short example code, and am able to shed some light on what the generated code is actually doing, as opposed to what it should have done.

The example source code:

program xpi
   implicit none
   integer, parameter :: nx = 2
   integer :: i, n = nx*4
   real :: x(4*nx) = (/ (1.0, 2.0, 3.0, 4.0, i=1,nx) /)
   real :: s

   s = sum((x(2:n-2:2)-x(3:n-1:2))**4)

   print *,s,' (expected: 83)'
end

The results that I obtained from FTN95 8.30.279:

-default-      26.3333
/opt           26.3333
/check         Internal compiler error
/checkmate     Internal compiler error

/64            21.0000
/64 /opt       21.0000
/64 /check      0.0000
/64 /checkmate  0.0000

Inspection of the /exp listings for some of the cases (where there is output and that output is not zero) shows that the 32-bit EXE actually computes sum((u-v)*3/v), and the 64-bit EXE actually computes sum(v(u-v)**3), where

u = x(2:n-2:2)

and v = x(3:n-1:2), instead of computing the requested result sum((u-v)**4)

Many thanks. I will make a note of this.

I wonder why it has taken so long to find this out?

Perhaps Holmes has the answer: 'Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.'

Could it be that no-one has ever used this form of statement? Or if they did, the result didn't matter? Or perhaps they blithely assumed the wrong answer was correct? Certain predictions in climate science leap instantly to mind.

My own guess is that the first is the real answer. After all, traditionally one would do it with some sort of explicit loop. I would, perhaps in so doing revealing that there are some parts of Fortran 90 et seq. that haven't entered my consciousness, or that within days of writing the statement I wouldn't have a clue what it did! (That is, if I could).

On a serious note, is it the raising to the power where the problem lies? I suspect so, because converting to repeated multiplication gives 83. And there was me, thinking that 42 was the answer to life, the universe and everything ...

Eddie

Quoted from John-Silver mecej4 - in your single lines quoted at top you've put **3 (twice) in error of **4 !!! Blame not the messenger!

The compiler emits machine code for two loops for Line-8. The first loop calculates the array valued expression to the right of '='. The second loop sums up the elements of the temporary array that the first loop filled in.

Here are the 32-bit assembler instructions in the first loop generated for Line-8 of the source code.

Label     __N3
      fld       X[ebx*8+4]        # u = X(i+1)
      fsub      X[ebx*8+8]        # v = X(i+2), u - v
      fst       Temp@9            # u-v
      fmul      Temp@9            # (u-v)**2
      fmul      Temp@9            # (u-v)**3
      fdiv      X[ebx*8+8]        # (u-v)**3/v
      fstp      [eax+ebx*4]       # store element of temporary result array
      inc       ebx               # increment i
      cmp       ebx,Temp@7        # loop count reached?
      jle       __N3

If any of the elements of v happen to be zero, doing '/v' with such an element will cause an FP 0-divide exception.