ifort 11 bug with function arguments, loop optimization, and -O3 -ipo

[Florian_Janoschek]

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.

[plain]module c_module
    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]

The output of both print statements should be '2' since s is reset to 0 before both j-loops.

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

The last point is probably the most interesting. I choose qsort here as an example because it should be available everywhere, is simple, and (hopefully) correct. However, the problem occurred whenever somewhere in the code (even in a never-called module function) there was a call to a subroutine with a function or a subroutine as argument.

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...

[Kevin_D_Intel]

Sounds like a very interesting issue. Thanks for the convenient reproducer. I will investigate and post again with updated information.

[Ron_Green]

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

[Florian_Janoschek]

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.

[Ron_Green]

this bug was fixed in 11.1.064 and greater compilers, including 'Composer XE 2011' versions (aka v12.0)

ron