Suspected optimizer bug

[mecej4]

The program below gives correct results when compiled with /Od, and incorrect results with /Ot or /O2. I suspect that this is an optimizer bug since, if one of the following slight changes is made, the bug goes away: (i) uncommenting the WRITE statement on line-29, (ii) commenting out the WRITE statement on line-37 or (iii) making the array A a statically allocated array.

The problem bears some resemblance to another optimizer bug with older versions of the Linux Ifort compilers that I reported on about a month ago ( http://software.intel.com/en-us/forums/showthread.php?t=73629 ); however, I thought that since I have now seen this bug with the Windows compiler, it might be appropriate to report it.

The results with /Od:

E:\\IBUG>ifort /Od tsc.f90 & tsc
Intel Visual Fortran Compiler Professional for applications running on IA-32, Version 11.1 Build 2010041
4 Package ID: w_cprof_p_11.1.065
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

Microsoft Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

-out:tsc.exe
-subsystem:console
tsc.obj
A2 = 1 2
A3 = 2 3
A4 = 1 2 3
Am = 1 2 3

and, with /O2:

E:\\IBUG>ifort /O2 tsc.f90 & tsc
Intel Visual Fortran Compiler Professional for applications running on IA-32, Version 11.1 Build 2010041
4 Package ID: w_cprof_p_11.1.065
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

Microsoft Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

-out:tsc.exe
-subsystem:console
tsc.obj
A2 = 2 2
A3 = 2 2
A4 = 1 2 2
Am = 1 2 2

The program source:

[fortran]program TSChur
  implicit none
  INTEGER, ALLOCATABLE, DIMENSION( : ) :: A

  allocate(A(3))

  call Scomp( A )

  write(*,10)' Am = ',A
  stop
10 format(1x,A10,3i4)

contains
      SUBROUTINE Scomp( A )

      implicit none
      INTEGER, ALLOCATABLE, DIMENSION( : ) :: A
      INTEGER, DIMENSION( 2 ) :: Kcol = (/1,2/)

      INTEGER :: i, i1, i2, ii, ij, ipos, j, j1, j2, jj
      INTEGER :: ls

      IF (.NOT.ALLOCATED(A))ALLOCATE(A(3))

      A( : 2 ) = 0
      DO ii = 1, 2
         A( Kcol( ii ) ) = A( Kcol( ii ) ) + 1
      END DO
!      write(*,10)' A1 = ',A(1:2)

      j = 1
      DO i = 1, 2
         ii = j
         j = j + A( i )
         A( i ) = ii
      END DO
      write(*,10)' A2 = ',A(1:2)

      DO i = 1, 2
         j = Kcol( i )
         jj = A( j )
         A( j )  = A( j ) + 1
      END DO
      write(*,10)' A3 = ',A(1:2)

      DO i = 2, 1, - 1
         A( i + 1 ) = A( i )
      END DO
      A( 1 ) = 1
      write(*,10)' A4 = ',A

      return
10 format(1x,A10,3i4)

      END SUBROUTINE Scomp

end program tschur
[/fortran]

[Steven_L_Intel1]

Thanks - I can reproduce this. We'll check it out.

[mecej4]

Thanks for looking into this bug. The bug is also present in the following older version for IA64 (sorry, I don't have access to an IA64 system with the current Intel Fortran Compiler installed):

[mecej4@login2 LANG]$ ifort -V
Intel Fortran IA-64 Compiler for applications running on IA-64, Version 10.1 Build 20080801 Package ID: l_fc_p_10.1.018
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.

[mecej4@login2 LANG]$ ifort -O2 tsc.f90
[mecej4@login2 LANG]$ ./a.out
A2 = 0 2
A3 = 1 3
A4 = 1 1 3
Am = 1 1 3

[mecej4@login2 LANG]$ ifort -O0 tsc.f90
[mecej4@login2 LANG]$ ./a.out
A2 = 1 2
A3 = 2 3
A4 = 1 2 3
Am = 1 2 3

[Steven_L_Intel1]

It looks as if this bug was recently fixed. I can reproduce it in Update 6, but not in what is eventually going to be Update 7.

[mecej4]

That's good news, thanks!