- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi!
I believe that I found a bug in ifort 11.0/11.1. As I understood I have to file my bug-report here, since I'm user of a non-commercial license.
The simplest code I could find that reproduces the problem is the following. It is mandatory that compilation was performed with both -O3 and -ipo.
However, the first print writes a '1' and this misbehavior depends on funny things (This unfortunately bloats the example code...) like
Looking at the machine code produced revealed that both additions and loops are all optimized away. Instead the results of both summations were directly mov'ed into some memory location. These constants, however were dependent on whether the subroutine call was commented out or not.
I hope I could help somebody with my report and of course I am curious about when this will be fixed...
I believe that I found a bug in ifort 11.0/11.1. As I understood I have to file my bug-report here, since I'm user of a non-commercial license.
The simplest code I could find that reproduces the problem is the following. It is mandatory that compilation was performed with both -O3 and -ipo.
[plain]module c_moduleThe output of both print statements should be '2' since s is reset to 0 before both j-loops.
implicit none
integer,parameter :: c(2) = (/0,1/)
end module c_module
integer(2) function cmp_function(a1,a2)
implicit none
integer(2) a1,a2
cmp_function = int(a1-a2,kind=2)
end function cmp_function
program bug
use c_module
use ifport
implicit none
integer,save :: i,j
integer,save :: blah(2),blub(2)
integer,save :: s(2)
integer(8),parameter :: len = 10,isize = 2
integer(2),save :: array(len)
integer(2),external :: cmp_function
do i=1,2
blah = 0
blub = 0
if (blah(1)==blah(2)) then
s = 0
do j=1,2
s = s + c
end do
end if
end do
print *,s(2)
s = 0
do j=1,2
s = s + c
end do
print *,s(2)
array = (/3,4,2,9,8,7,1,6,5,0/)
call qsort(array,len,isize,cmp_function)
print *,array
end program bug
[/plain]
However, the first print writes a '1' and this misbehavior depends on funny things (This unfortunately bloats the example code...) like
- the existence of the assignment blub = 0
- the definition of c in a module outside the program
- c being a vector
- the existence of the qsort call
Looking at the machine code produced revealed that both additions and loops are all optimized away. Instead the results of both summations were directly mov'ed into some memory location. These constants, however were dependent on whether the subroutine call was commented out or not.
I hope I could help somebody with my report and of course I am curious about when this will be fixed...
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sounds like a very interesting issue. Thanks for the convenient reproducer. I will investigate and post again with updated information.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The bug report is DPD200139988
Kevin asked me to look into this error.
There is an interaction between -O3 and -ipo. I have found several good workarounds. You can use any of the below to avoid the issue. I've sorted this top to bottom, the top being what will probably be the least performance impact, the lower sets are probably higher impact (roughly, hard to tell without the actual code):
-O3 -ipo -no-ansi-alias
-O2 -ipo
-O3 -ip
-O1
-O0
I think adding -no-ansi-alias will be the least impact, but it can depend on the real code. I am assuming this example is a much stripped down version of an actual code.
I cannot guarantee when a fix will appear. We just missed an update compiler release, so the next release may be 3 months away. And high-risk fixes that affect the internals of the high-level optimizer and IPO (fixes that impact a lot of code paths) may get rolled up into the next major release which is over a year away.
For the time being, try the first 2 sets of options above. Either of these should balance performance with correct results.
ron
Kevin asked me to look into this error.
There is an interaction between -O3 and -ipo. I have found several good workarounds. You can use any of the below to avoid the issue. I've sorted this top to bottom, the top being what will probably be the least performance impact, the lower sets are probably higher impact (roughly, hard to tell without the actual code):
-O3 -ipo -no-ansi-alias
-O2 -ipo
-O3 -ip
-O1
-O0
I think adding -no-ansi-alias will be the least impact, but it can depend on the real code. I am assuming this example is a much stripped down version of an actual code.
I cannot guarantee when a fix will appear. We just missed an update compiler release, so the next release may be 3 months away. And high-risk fixes that affect the internals of the high-level optimizer and IPO (fixes that impact a lot of code paths) may get rolled up into the next major release which is over a year away.
For the time being, try the first 2 sets of options above. Either of these should balance performance with correct results.
ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the quick reply and the information about compiler releases!
I actually encountered this issue in an interpolation function that was part of a fluid mechanics simulation code. As you assumed, the first three of the sets of options do not show a significant effect on its performance, so I will probably use "-O3 -ipo -no-ansi-alias" now.
I actually encountered this issue in an interpolation function that was part of a fluid mechanics simulation code. As you assumed, the first three of the sets of options do not show a significant effect on its performance, so I will probably use "-O3 -ipo -no-ansi-alias" now.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
this bug was fixed in 11.1.064 and greater compilers, including 'Composer XE 2011' versions (aka v12.0)
ron
![](/skins/images/45C6C2D737ED71F4C51F0145C8CB1E9C/responsive_peak/images/icon_anonymous_message.png)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page