Quantcast
Channel: Intel® Fortran Compiler
Viewing all articles
Browse latest Browse all 3270

Possible Bug in Intel 15

$
0
0

Hello,

I've been working on a project that is compiled under a few different compilers for regression testing, and when we got to intel 15 for some reason a few cases encountered a divide by zero error.  I think that I've tracked the problem to a loop, and been able to reproduce it.  It's not a huge deal, and I think can actually be fixed with just compiler flags, I just wanted to get some thoughts on it.  I have two files, because I think the compiler optimizes differently when it has the number on hand than when it gets it passed in from somewhere else.  I'm also not sure if this problem still exists, as we're running on an older (a few months) than current version of Intel 15.

module test_abs

contains

subroutine test(factor)
  implicit none
  integer :: n
  !
  real :: temp
  real :: a,asqr
  !
  real, dimension(2) :: answer
  real, intent(in) :: factor
  !
continue
  do n = 1,2
    asqr = factor * .7143
    a = sqrt(asqr)

    temp = 1.5
    temp = broke_fun(temp,.15,1E-17)

    answer(n) = temp
!write(*,*) 'fix'
  end do
write(*,*) answer(1)
end subroutine test

pure elemental function broke_fun(original,del,elim)
  implicit none
  real, intent(in) :: original,del,elim
  real             :: broke_fun
continue
  broke_fun = del + max(original-del, &
                          min(0.0, &
                              0.5*(original*original-del*del)/(max(del,elim))))
end function broke_fun

end module test_abs

And then the second file which uses this subroutine:

program main
use test_abs

  call test(1.4000000)

end program

The issue is that if you run the program as is, the answer given will be .15 when I think it should be 1.5.  If you remove the '!' in the "write(*,*) 'fix'" line, the answer given is 1.5.  I believe this is something to do with how the loop is optimized.  Obviously I can't just throw a write fix into a loop in the actual code, and I've tried !DIR$ SIMD_OFF NOVECTOR, NOFUSION, INLINE, but I think the problem is with the compiler flags.  These flags were picked because regression testing tends to start failing (we don't have fuzzy testing) when optimizing.

I've compiled with ifort -O2 -fp-model strict -fno-inline -ftrapuv *.F90 and when I remove either the -fp-model strict or the -fno-inline the problem disappears.  If I remove the -ftrapuv, the .15 becomes more or less random.

Thanks,

Doug


Viewing all articles
Browse latest Browse all 3270

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>