OpenMP collapse error with stride

[David_Bal]

I have discovered errors when using the collapse statement with OpenMP using Intel Fortran.  Below is test code that produces the errors.  The error is that the variable b doesn't increment from 5 to 15, but instead stays at 5.  I am using ifort version 14.0.3.

program test
implicit none
integer :: a,b,c,a1,b1,c1,a2,b2,c2,a3,b3,c3
a1=1; b1=7; c1=3
a2=5; b2=15; c2=5
a3=12; b3=18; c3=3

    !$omp parallel do collapse(3)
    do a = a1,b1,c1
    do b = a2,b2,c2
!    do b = a2,b2,5 ! replace c2 with 5 and correct results occur
    do c = a3,b3,c3
    write (*,*) a,b,c
    end do
    end do
    end do
    !$omp end parallel do

end program test

Below is another example of a similar problem.  This time I use a derived type for the loop bounds and stride.  Now not only is variable b stuck at the initial value (5), but also variable a is completely out of bounds and goes on forever.  If I replace all the variable strides with constants correct results occur.

program test2
    implicit none
type first_last_step
   integer :: first             ! beginning of loop
   integer :: last              ! end of loop
   integer  :: stride           ! loop step increment
end type first_last_step

type (first_last_step) :: e,f,g
integer :: a,b,c
e%first=1; e%last=7; e%stride=3
f%first=5; f%last=15; f%stride=5
g%first=12; g%last=18; g%stride=3

    !$omp parallel do collapse(3)
    do a = e%first,e%last,e%stride
!    do a = e%first,e%last,3        ! replace stride with constant and works correctly
    do b = f%first,f%last,f%stride
!    do b = f%first,f%last,5        ! replace stride with constant and works correctly
    do c = g%first,g%last,g%stride
!    do c = g%first,g%last,3        ! replace stride with constant and works correctly
    print *,a,b,c
    end do
    end do
    end do
    !$omp end parallel do

end program test2

Both examples perform correctly in GFortran, but I would prefer to use Intel Fortran due to its higher performance.  Can these errors be fixed?

Thanks

[Kevin_D_Intel]

I reproduced the behavior you described using both ifort and gfortran. The incorrect results also occur with our release due out later this year. I directed the issue to Development (see internal tracking id below) for further investigation and will keep you posted on any updated status as I learn it.

(Internal tracking id: DPD200357400)