2 Oct 2018 4:41
#22618
For the test program below, the expected output result is ' slope = 7.00000'. FTN95 8.30, 32 and 64 bit, gives this result except when /undef or /checkmate is used, in which case the erroneous output 'slope = 0.00000' is produced. Versions 7.2 and 6.35 do not have this bug.
program ex2
implicit none
integer :: m = 5, j1
real , dimension(5) :: x, alpha
real :: slope, prdct
real, allocatable :: r1v(:)
logical, allocatable :: l1v(:)
!
data x / -2.0, -1.0, 1.0, 2.0, 4.0 /
data alpha / -1.0, -7.0, 7.0, 5.0, 3.0 /
data prdct / 1.5 /
!
slope = 0.
allocate (l1v(m), r1v(m))
l1v = (/(j1, j1=1, m)/) /= 1
where (l1v)
r1v = (alpha(1) + alpha)/(x(1) - x)
elsewhere
r1v = 0
end where
slope = (slope + sum(r1v, mask=l1v))*prdct
deallocate (l1v, r1v)
print *,'slope = ',slope
stop
end program
Inspecting the 32-bit /exp listing shows that the problem is with the code generated for the WHERE construct. The address of L1V is held in register ECX. After each iteration of the block, ECX should be incremented by 4, but this instruction is missing. As a result, the mask used is L1V(1), L1V(1),... instead of L1V(1), L1V(2), ...
A strange example of an anti-Heisenbug!