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

Compiler bug in version 17

John_D_12
Beginner
676 Views

I think there may be an obscure bug in Intel Fortran Version 17 which breaks our electronic structure code (http://elk.sourceforge.net/).

It's a bit tricky to reproduce but I've simplified it as far as I can.

You need the following module file (modtest.f90):

module modtest

integer m,n
integer k(2)
real(8), allocatable :: ev(:,:)

end module

and the following program (test.f90):

program test
use modtest
implicit none

integer i,j
real(8) ef,e0,e1,e

m=10
n=8

allocate(ev(m,n))
call random_number(ev(:,:))

ef=0.5d0

e0=-1.d8
e1=1.d8

do j=1,n
  do i=1,m
    e=ev(i,j)
    if (e.lt.ef) then
      if (e.gt.e0) then
        e0=e
        k(1)=j
      end if
    else
      if (e.lt.e1) then
        e1=e
        k(2)=j
      end if
    end if
  end do
end do

print *,e0,e1

end program

 

The the module and the program have to be in separate files.

 

If I compile with version ifort 17 as follows:

ifort -O2 modtest.f90 test.f90

... the code produces:

-100000000.000000        100000000.000000

 

If I compile with version 16, I get correctly:

  0.494784114443067       0.523222485777880

 

The code works fine if the variables in modtest are transferred to the program; or if the module and program are combined into a single file. It works if you insert a print statement in the inner loop. If the array k(2) is changed to two variables, say k1, k2, then the code also works.

The bug seems to be related to optimization: using -O0 or -O1 produces the correct output.

 

Additional info:

>uname -or
3.10.0-514.21.1.el7.x86_64 GNU/Linux

>lsb_release -irc
Distributor ID:	CentOS
Release:	7.3.1611
Codename:	Core

>ifort --version
ifort (IFORT) 17.0.0 20160721
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

 

I hope you can reproduce it.

 

Regards,

John.

 

0 Kudos
7 Replies
Xiaoping_D_Intel
Employee
676 Views

Thanks for reporting this issue. I can reproduce the error and found it no longer happens in the 18.0 beta compiler. You may try the beta compiler by following: https://software.intel.com/en-us/articles/intel-parallel-studio-xe-2018-beta

 

Thanks,

Xiaoping Duan

Intel Customer Support

0 Kudos
jimdempseyatthecove
Honored Contributor III
676 Views

Xiaoping,

It might be reassuring to John, and others, if you check the change log and verify/report if this particular bug has been corrected. The mere running of the program, and getting correct results, does not confirm the bug was fixed. IOW the correct result was coincidental. i.e. inserting print statement altered code placement and code optimization resulting in correct result. V18 of compiler may have relocated the code and now accidentally produces the correct result.

Jim Dempsey

0 Kudos
Xiaoping_D_Intel
Employee
676 Views

jimdempseyatthecove wrote:

Xiaoping,

It might be reassuring to John, and others, if you check the change log and verify/report if this particular bug has been corrected. The mere running of the program, and getting correct results, does not confirm the bug was fixed. IOW the correct result was coincidental. i.e. inserting print statement altered code placement and code optimization resulting in correct result. V18 of compiler may have relocated the code and now accidentally produces the correct result.

Jim Dempsey

 

Thanks for the comments. I checked the code and found the reason of no error in 16.0 and 18.0 is no vectorization for the inner loop at line 20 of test.f90. This loop was incorrectly vectorized in 17.0 and produced the wrong output. 

 

I have opened a bug report for it and the bug ID is CMPLRS-43669

 

Thanks,

Xiaoping Duan

Intel Customer Support

0 Kudos
mecej4
Honored Contributor III
676 Views

Duan X., would it be correct to infer that generating vectorization reports with versions 16.x and 17.y and comparing the reports would have revealed the incorrect vectorization of 17.y? In other words, would generating such reports be a tool that the end user can use to pinpoint compiler bugs of this type?

0 Kudos
jimdempseyatthecove
Honored Contributor III
676 Views

Mecej4,

The vectorization reports informs you if sections of code were or were not vectorized, and optionally informs you why. The report does not tell you in detail how the code was vectorized. You have to look at the disassembly for this.

Jim Dempsey

0 Kudos
John_D_12
Beginner
676 Views

jimdempseyatthecove wrote:

Xiaoping,

It might be reassuring to John, and others, if you check the change log and verify/report if this particular bug has been corrected. The mere running of the program, and getting correct results, does not confirm the bug was fixed. IOW the correct result was coincidental. i.e. inserting print statement altered code placement and code optimization resulting in correct result. V18 of compiler may have relocated the code and now accidentally produces the correct result.

Jim Dempsey

 

You are absolutely correct. The problem still occurs even after compiling in our electronic structure code (http://elk.sourceforge.net/) with version 18. The simplified example above now works OK with v.18 implying that the vectorization is still buggy but now not applied in the same way.

I'm not sure how to coax the compiler into vectorizing test.f90. Alternatively, you could download Elk and compile it. The routine where the problem occurs is occupy.f90 (the example above is a simplified version of this routine).

 

Regards,

John.

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
676 Views

You have the compiler directives

!DIR$ VECTOR [clause[, clause[,...]]]
   and
!DIR$ NOVECTOR

This may assist you into fine tuning the performance (and tuning out the error).

Jim Dempsey

0 Kudos
Reply