strange bug

[kissin__yoel]

 Hi

I am encountering a strange bug that gives me a slightly wrong/different output for a matrix transformation which I have simplified below. The difference is not present if I run with -debug, or, strangely, if I uncomment a print statement in the loop. Or even if I allocate the mat_out array with the number 67 without using the variable dim. It's clear that there are no out of bounds references or other errors in this simple code. The difference is very slight, but it is nonetheless annoying/worrying me.

This bug does not happen if I use gfortran compiler.

 program sample
implicit none
 integer :: dim, i, j, k
 real*8:: b
 real*8 ,allocatable:: mat_a(:,:), mat_b(:,:), mat_out(:,:)
 dim=67
allocate (mat_out(dim,dim),mat_a(dim,dim),mat_b(dim,dim))
read (100) mat_a,mat_b
j=66
  do i=65,64,-1
      b=0. 
 do k=1, i 
   b=b+mat_a(i,k)*mat_b(k,j)
  enddo
mat_out(i,j)=b
!print*, mat_out(i,j)
  enddo
 print'(1d25.16)',mat_out(64,66)

 end program sample

[kissin__yoel]

I'm not trying to reach a dogmatic result, I'm just bothered by one thing - that the output changes as a result of cosmetic changes to the code (print statement etc). I would assume that this sort of behaviour is unintended and indicative of some sort of bug -as opposed to different compiler options which I understand can change the method in which the processor carries out the calculation...

[Steve_Lionel]

There's no evidence of a bug, just the normal one as presented by others here that any change in the order of operations can change results. Adding print statements forces results to memory and inhibits many optimizations.

[andrew_4619]

did you read the link others referenced above? That explains a lot.

http://sc13.supercomputing.org/sites/default/files/WorkshopsArchive/pdfs/wp129s1.pdf

[kissin__yoel]

yes I did thanks.

Is -ffast-math equivalent to /fp:fast in the Visual Studio environment? Is fast the default option for O2, because this discrepancy only happens when it is set to fast, rather than strict or precise.

But presumably I can run with optimizations, but set /fp:strict as well.

According to microsoft documentation

The /fp:fast option allows the compiler to reorder, combine, or simplify floating-point operations to optimize floating-point code for speed and space. The compiler may omit rounding at assignment statements, typecasts, or function calls. It may reorder operations or perform algebraic transforms, for example, by use of associative and distributive laws, even if such transformations result in observably different rounding behavior.

Thanks!

[Steve_Lionel]

Look at the Intel documentation, not Microsoft, though the description is similar.