Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
27415 Discussions

Array multiplication vs element multiplication discrepancy


I discovered a discrepancy between array multiplication and element multiplication with the Intel Fortran compiler, and have a small reproducer here. Is this expected behavior? The discrepancy is very small (seems like one bit), and it only occurs with -O2 and higher, so it seems like an optimization bug to me. I tested it on three machines: a Xeon E5-2650 v3, a Xeon E5-2697 v3, and an i7-6600U.

Any insights on this? Thanks!


! Compiled with:
!   ifort -o array_mult_disc array_mult_disc.F90
! Tested with Intel 17.0.6 and 18.0.3. The discrepancy is not
! reproduced with -O0 or -O1, nor is it reproduced by gfortran
! or nagfor compilers.
! Demonstrates discrepancy with array and element-wise multiplication
! with Intel Fortran. Order of operations remains the same, but whether
! performing array multiplication, element multiplication, or element
! multiplication of a copy, different answers are produced.

program array_mult_disc

  use,intrinsic :: iso_fortran_env, only: r8 => real64
  implicit none

  real(r8) :: t1, t2

  ! if the dimension here is set to 1, both discrepancies disappear
  real(r8), dimension(2) :: a, b, c, d, e

  a = 1.0_r8 / 3.0_r8
  b = 1.0_r8 / 7.0_r8
  c = 1.0_r8 / 13.0_r8

  ! array multiplication produces a different
  ! result than element multiplication
  e = (a * b) * c
  t1 = (a(1) * b(1)) * c(1)
  print '(es30.20)', t1
  print '(es30.20, es13.3)', e(1), e(1) - t1

  ! element multiplication of a copy produces
  ! a different result than the original
  d = c
  t2 = (a(1) * b(1)) * d(1)
  print '(es30.20, es13.3)', t2, t2 - t1

  ! The following line is necessary for the second discrepancy to appear
  print '(es13.3)', d(1)

end program array_mult_disc


0 Kudos
2 Replies
Black Belt

It is not a bug.  By default, certain optimisations are enabled that may result in small variations in the results of floating point calculations.  You can disable those optimisations with appropriate compile options. has more information.


Thank you, that was exactly it. "-fp-model precise" removes the discrepancy.