Loop nest parallelized with !$omp parallel do collapse() does not run

Loop nest parallelized with !$omp parallel do collapse() does not run

Compile the following test program ifort 13.0.

program test integer i, j double precision, allocatable :: a(:, :) allocate(a(5, 6)) !$omp parallel do collapse(2) private(i, j) do j = 1, 6 do i = 1, 5 a(i, j) = i * 10 + j end do end do !$omp end parallel do print *, a !$omp parallel do collapse(2) private(i, j) do i = 1, size(a, 1) do j = 1, size(a, 2) !$omp critical print *, a(i, j) !$omp end critical end do end do !$omp end parallel do end program

When the program is run, no output is produced from the second loop nest.

10 posts / novo 0
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

Thank you for the nice reproducer. Unclear whether the root cause is tied to collapse or size() in the second loop nest. The second loop nest runs w/o collapse but w/size, or w/o size but w/collapse. I reported to Development (internal tracing id below) for further analysis and will update once I learn more.

(Internal tracking id: DPD200237575)

Citação:

Kevin Davis (Intel) escreveu:

Thank you for the nice reproducer. Unclear whether the root cause is tied to collapse or size() in the second loop nest. The second loop nest runs w/o collapse but w/size, or w/o size but w/collapse. I reported to Development (internal tracing id below) for further analysis and will update once I learn more.

(Internal tracking id: DPD200237575)

This is another troubling case involving the collapse clause.

program test
    integer s(3), e(3), i, j, k, l
    s = 1
    e = 64
    !$omp parallel do collapse(2) private(i, j, k, l)
    do l = 1, 2
        do j = s(2), e(2)
            do k = s(3), e(3)
                do i = s(1), e(1)
                    !$omp critical
                    print *, i, j, k, l
                    !$omp end critical
                end do
            end do
        end do
    end do
end program

The program outputs only 8192 lines instead of the expected 524,288. Notice that j only ever takes two values (1 and 2).

I need an immediate workaround for this problem. Please confirm if using scalar variables for loop bounds always works.

I'd certainly hesitate to say "always" but I've had better luck with getting fixes for collapse with scalar loop bounds known at compile time, and my broken cases involve variable sizes.

Unfortunately I can only produce correct results w/o collapse. I reported this case separately and requested advice for any other work around.

(Internal tracking id: DPD200237626)

(Resolution Update on 02/08/2013): This defect is fixed in the Intel Fortran Composer XE 2013 Update 2 (2013.2.146 - Linux) 

I thought the second case was fixed in our latest XE 2013 Update 1, but that appears not to be true. Still awaiting resolution of both cases.

For a work around, remove the collapse, swap the "do l" and "do j" lines.
This will change the sequence.
An alternative work around:
s = 1
e = 64
!$omp parallel private(i, j, k, l)
do l = 1, 2
!$omp do
do j = s(2), e(2)
do k = s(3), e(3)
do i = s(1), e(1)
!$omp critical
print *, i, j, k, l
!$omp end critical
end do
end do
end do
!$omp barrier
end do

Jim Dempsey

www.quickthreadprogramming.com

(forum double posted message removed)

www.quickthreadprogramming.com

The second defect (DPD200237626) is fixed in the Intel Fortran Composer XE 2013 Update 2 (2013.1.146 - Linux).

Still awaiting resolution of the first defect (DPD200237575).

(Resolution Update on 07/23/2013): This initial defect (DPD200237575) was fixed in the Intel Fortran Composer XE 2013 Update 3(2013.2.163 - Linux). 

Pardon the overdue reply. The first defect (DPD200237575) was fixed in the Intel Fortran Composer XE 2013 Update 3 (2013.1.163 - Linux).

Deixar um comentário

Faça login para adicionar um comentário. Não é membro? Inscreva-se hoje mesmo!