Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

problem with optimization flags


I am encountering a strange problem with the fortran intel 17.0.0 compiler (as obtained through “ifort –v”) when compiling with optimization flags with arrays.
After a series of tests I created the following very simple code to test what is happening.

 program matrix_define

     implicit none

     integer, parameter :: dimen = 3
     real*8 :: A(2, dimen)
     real*8 :: x(3,dimen)

     x(1,1) = 5.d0
     x(1,2) = 2.d0
     x(1,3) = 1.d0

     x(2,1) = 1.d0
     x(2,2) = 2.d0
     x(2,3) = 3.d0

     x(3,1) = 0.d0
     x(3,2) = 0.d0
     x(3,3) = 0.d0

    A(2,1:3) = x(1,1:3) - x(2,1:3)
    A(1,1:3) = x(3,1:3) - x(2,1:3)

    write(*,*) A(1,1:3)
    write(*,*) A(2,1:3)

    end program  matrix_define

As you notice it is a very simple test. It mainly consists of defining the components of a two-dimensional array A(2,3). When I compile using “ifort” without any flags the program assigns the correct values for all A-array elements.
However, when compiling with “ifort –fast” the output values of A are messed up:
The element A(1,2)  has the value of A(2,1) while A(2,1) and all other element values are as they should.

I have tested the same code with the same options with intel fortran 12.0 and 10.0 and no problem appears.

Is it possible that there a problem in arrays with optimization flags in intel fortran 17.0?

Thank you very much for your time and efforts!


0 Kudos
1 Reply
Black Belt

With my copy of 17.0.1 64-bit, I get the same result with or without -fast.  It does emphasize that you are right not to set -fast blindly.

I have frequently got bad results in recent compilers with combinations of options which are set by -fast, although I don't like to use the entire group.  I had an IPS problem report on the subject which was removed from my view recently without notice, so perhaps the compiler team believes it has been corrected.