Bug in code generation when /fp:fast is used

[witfort]

Hello,

I believe that I have discovered a compiler bug in the Intel Visual Fortran Compiler XE 12.1.1.258.

When the /fp:fast compiler option is active, the attached test program generates incorrect numerical results in the section of code within Example 1. The mere addition of a write statement in Example 2 appears to cause the correct numerical results to be generated. For this test program, this bug shows up in both the Win32 and x64 versions. It originally came to my attention in the x64 version of a program that I've been working on.

When /fp:fast is replaced by /fp:source, both Example 1 and Example 2 produce the same numerical answers.

[Steven_L_Intel1]

I don't know if I'd call this a bug - it might or might not be. The loop without the WRITE gets vectorized, the one with the WRITE doesn't. There may be some cancellation going on here - I will take a closer look.

[jimdempseyatthecove]

Steve,

The optimizer might not view the results of the first loop's use of el as being used (even though it is clearly used the write statement following loop 1. To test this add el1(3), el2(3) to the real(8) then after loop 1 add "el1=el" and after loop 2 add "el2=el" followed by an innocuous test:

do i=1,3
if(el1(i) .ne. el2(i)) write(*,*) "mismatch", i
end do

If with the edits, the error goes away, then this points to a compiler optimization issue (bug) with.

write(*,'(f15.6)') el

as to not referencing all elements of el, and the dead code elimination results in value not calculated.

Jim Dempsey

[witfort]

I've made the changes suggested by Jim, and the error is still there. "Mismatch in element 1" is what I get.

Note that I also modified my original code that used "write(*,'(f15.6)') el" to now be "write(*,'(f15.6)') (el(i),i=1,3)", which now explicitly accesses each of the three elements in array el. The arithmetic isn't particularly difficult, but the compiler does seem to get it wrong.