Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
For the latest information on Intel’s response to the Log4j/Log4Shell vulnerability, please see Intel-SA-00646
26857 Discussions

Optimizer bug in Intel Fortran Compiler 17.0

mecej4
Black Belt
152 Views

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

 

0 Kudos
8 Replies
Steven_L_Intel1
Employee
152 Views

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
New Contributor I
152 Views

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

Steven_L_Intel1
Employee
152 Views

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
New Contributor I
151 Views

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

Peter

Kevin_D_Intel
Employee
152 Views

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

Pierre-Marie_B_
Beginner
152 Views

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

mecej4
Black Belt
152 Views

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
Employee
152 Views

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.

Reply