Optimizer bug in Intel Fortran Compiler 17.0

[mecej4]

Here is a simplified reproducer for an optimizer bug of IFort 17.0 that was to blame for the bugs shown in a contemporary post (https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/685333). The bug is rather fragile, and small changes to the code can make it go away. To reproduce the bug, put the sources into separate files, and compile the two files with the option /Ot or /O2. The bug is not seen if /Od is used, or with previous versions of the compiler.

File tst.f:

      Program TST

      IMPLICIT NONE
      INTEGER  I
      REAL     Array(8)

      DO I=1,8
         Array(I)=I
      ENDDO
      call ArrayTest(array,8,1)

      END PROGRAM

File asub.f:

      SUBROUTINE ArrayTest(Array2D,Rows,Cols)

      IMPLICIT NONE
      INTEGER  Rows,Cols
      INTEGER*2 J
      REAL     Array2D(rows,cols),Array1D(rows)

      DO J=1,rows
         Array1D(J)=Array2D(J,1)
      ENDDO
      WRITE(*,'(A,12(1X,F8.4))') 'Array1D = '
     +                                ,(Array1D(J),J=1,rows)
      RETURN
      END

The correct output is

Array1D =    1.0000   2.0000   3.0000   4.0000   5.0000   6.0000   7.0000   8.0000

but, because of the optimizer bug, the actual output is

Array1D =    1.0000   2.0000   3.0000   4.0000   1.0000   2.0000   3.0000   4.0000

Comparing the assembly listings obtained with /Ot with IFort 16and IFort 17  (both 32-bit) displays the code generation problem:

With 16.0.3:

.B1.4:                          ; Preds .B1.4 .B1.3
        movups    xmm0, XMMWORD PTR [-4+edi+edx*4]              ;9.10
        movups    xmm1, XMMWORD PTR [12+edi+edx*4]              ;9.10
        add       eax, 8                                        ;8.7
        movaps    XMMWORD PTR [-4+esi+edx*4], xmm0              ;9.10
        movaps    XMMWORD PTR [12+esi+edx*4], xmm1              ;9.10
        add       edx, 8                                        ;10.7

With 17.0:

.B1.4:                          ; Preds .B1.4 .B1.3
        movups    xmm0, XMMWORD PTR [-4+edi+edx*4]              ;9.10
        add       eax, 8                                        ;8.7
        movups    XMMWORD PTR [-4+esi+edx*4], xmm0              ;9.10
        movups    XMMWORD PTR [12+esi+edx*4], xmm0              ;9.10
        add       edx, 8                                        ;10.7

[Steven_L_Intel1]

Thanks - I can reproduce this. Making the array index J default integer (INTEGER(4)) avoids the problem. I will send this on to the developers. Issue ID is DPD200414427.

[schulzey]

Steve, do you know if this issue has been addressed in the 2017 Update 1 released today?

[Steven_L_Intel1]

No, it has not yet been fixed. I have pinged the developers to see where they are on it. There has been initial triage on it - the vectorizer is not handling the INTEGER(2) case here correctly.

[schulzey]

Hi Steve, do you know if this issue has been fixed in Update 2?

Peter

[Kevin_D_Intel]

Yes, I confirmed the fix for the reported issue is in PSXE 2017 Update 2.

[Pierre-Marie_B_]

Hi, seems to be still there in update2... Any update ?

[mecej4]

My tests show that it has been fixed in 17.0.2. If you still see it, please provide more details about your environment (VS version, compiler options used, OS).

[Kevin_D_Intel]

I concur with mecej4. The issue is fixed in PSXE 2017 Update 2. I went back and re-tested his test case in reply #1 and the original test case from the forum post cited in post #1 and can show both now produce expected results with update 2.

If you are experiencing failures with update 2 then perhaps you have a variant on the original issue or a different issue in which case please provide the details requested and a complete reproducer that we can investigate further.