Joined: 31 Oct 2006
|Posted: Tue Oct 02, 2018 5:41 pm Post subject: Bad code generated with /undef or /checkmate
|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.
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
r1v = (alpha(1) + alpha)/(x(1) - x)
r1v = 0
slope = (slope + sum(r1v, mask=l1v))*prdct
deallocate (l1v, r1v)
print *,'slope = ',slope
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!