- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page