Openmp task bug

[Patrice_l_]

Hi all ,

I got a weird behavior with the following code, looks like the variables are not correctly shared. No problem with gfortran, I'm using 15.1.

module pp
type qq
double precision,dimension(:),allocatable :: f
end type
contains
subroutine t()
type(qq),allocatable :: ff
double precision,dimension(:),allocatable :: f
integer :: i,j
i=100
!$omp task
print *,i
!$omp end task
!$omp task
allocate(f(10))
f=2
print *,'f',f
deallocate(f)
!$omp end task
!$omp task
call lili()
!$omp end task
contains
subroutine lili
print *,i
end subroutine
end subroutine
end module pp

program toto
use pp
implicit none
call t()
end program

[Patrice_l_]

The value of i in the subroutine is not 100.  When used with omp parallel and omp single, its give the right value of i when the thread executing the task is the master, despite the shared.

 OMP_NUM_THREADS=2 ./a.out
         100
 f   2.00000000000000        2.00000000000000        2.00000000000000     
   2.00000000000000        2.00000000000000        2.00000000000000     
   2.00000000000000        2.00000000000000        2.00000000000000     
   2.00000000000000     
     8064112
 OMP_NUM_THREADS=2 ./a.out
     8064112
 f   2.00000000000000        2.00000000000000        2.00000000000000     
   2.00000000000000        2.00000000000000        2.00000000000000     
   2.00000000000000        2.00000000000000        2.00000000000000     
   2.00000000000000     
         100

[jimdempseyatthecove]

module pp
type qq
double precision,dimension(:),allocatable :: f
end type
contains
subroutine t()
type(qq),allocatable :: ff
double precision,dimension(:),allocatable :: f
integer :: i,j
i=100
!$omp task
print *,i
!$omp end task
!$omp task
allocate(f(10))
f=2
print *,'f',f
deallocate(f)
!$omp end task
!$omp task
call lili()
!$omp end task
!$OMP TASKWAIT ! ********** add this ***********
contains
subroutine lili
print *,i
end subroutine
end subroutine
end module pp

program toto
use pp
implicit none
call t()
end program

Jim Dempsey

[jimdempseyatthecove]

From the user reference guide on TASK

Note that when storage is shared by an explicit task region, you must add proper synchronization to ensure that the storage does not reach the end of its lifetime before the explicit task region completes its execution.

Jim Dempsey

[Patrice_l_]

Thanks, I forgot that one. Right now I am running into a catastrophic error using those options :   -qopenmp     -O2 -fp-model source -xHost 

LOC_type is: 1
101000_1

catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.

Any ideas to have more clues ?

Actually in my full code, event with the taskwait i got the problem that in the subroutine (lili) inside the task i have a value = 0, but inside the task but outside of the subroutine (lili) i have the right value. Plus , I use a class procedure, might be a little more complicated. I will try to put down a case.

[Patrice_l_]

jimdempseyatthecove wrote:

module pp
type qq
double precision,dimension(:),allocatable :: f
end type
contains
subroutine t()
type(qq),allocatable :: ff
double precision,dimension(:),allocatable :: f
integer :: i,j
i=100
!$omp task
print *,i
!$omp end task
!$omp task
allocate(f(10))
f=2
print *,'f',f
deallocate(f)
!$omp end task
!$omp task
print *,'Thread:',omp_get_thread_num(),'lili',i  !!!!!!! adding this
call lili()
!$omp end task
!$OMP TASKWAIT ! ********** add this ***********
contains
subroutine lili
print *,i
end subroutine
end subroutine
end module pp

program toto
use pp
implicit none
call t()
end program

Jim Dempsey

Adding the print beofre the call, show that the value i is shared correctly.

I get the error when i compile with -g -C  then instead of

                 100
 f   2.00000000000000        2.00000000000000        2.00000000000000     
   2.00000000000000        2.00000000000000        2.00000000000000     
   2.00000000000000        2.00000000000000        2.00000000000000     
   2.00000000000000     
 i           0                   100

I get :

                 100
 f   2.00000000000000        2.00000000000000        2.00000000000000     
   2.00000000000000        2.00000000000000        2.00000000000000     
   2.00000000000000        2.00000000000000        2.00000000000000     
   2.00000000000000     
 i           0               6978048

Thanks.

[Patrice_l_]

I think i figured it out. With such a small example the compiler is inlining the function so here is my example and command line to  trigger the bug.  ifort -O2  -fno-inline-functions   -qopenmp test.f90

thanks.

module pp
use omp_lib
type qq
double precision,dimension(:),allocatable :: f
end type
contains
subroutine t()
type(qq),allocatable :: ff
double precision,dimension(:),allocatable :: f
integer :: i,j
i=100
!$omp parallel
!$omp single
!$omp task
print *,i
!$omp end task
!$omp task
allocate(f(10))
f=2
print *,'f',f
deallocate(f)
!$omp end task
!$omp task
print *,'Thread:',omp_get_thread_num(),'lili',i  !!!!!!! adding this
call lili()
!$omp end task
!$omp end single
!$omp end parallel
contains
subroutine lili
print *,i
end subroutine
end subroutine
end module pp

program toto
use pp
implicit none
call t()
end program

[Martyn_C_Intel]

I was able to reproduce the problem using your last example. I see no reason why host association should not work for a shared variable, even within an OpenMP task. I am escalating this to the compiler developers; we'll let you know what they say.

     In your code, i is a local variable that gets put on the stack. If you make it static, with

INTEGER :: SAVE, i

then your code works as expected, so this may be a workaround. You should not make all variables static, because the default of 'automatic' with -qopenmp is needed to ensure thread safety in case a subroutine is called from within an OpenMP construct in the calling routine.

[Martyn_C_Intel]

This is indeed a bug. A fix is targeted for the version 16 compiler, currently in beta testing. The fix is targeted for the next update to the beta compiler in a couple of weeks or so. If you are interested in joining the beta test program to try this out, please let us know.

[Martyn_C_Intel]

Steve's post at the top of this forum points to an FAQ and link for signing up for the 16.0 compiler beta test program:

https://software.intel.com/en-us/forums/topic/549312

[Patrice_l_]

Thank you for letting me know, I'll register for the beta.

[Martyn_C_Intel]

That beta update compiler with the fix is now available. (16.0.0.026).

[Patrice_l_]

This bug is still present in the beta update 1 I have.

[Martyn_C_Intel]

I had confirmed that the bug was fixed in the slightly simplified test case that was sent to the developers.

I'm surprised, but I agree that it does not seem to be fixed in your exact code. Sorry about that; I will send it back to the developers.

[Martyn_C_Intel]

It turned out there was a nuance that was not captured by the fix to the reduced test case. The fix has been extended and I have confirmed that your test case ran correctly in the development compiler. The fix should be available in the 16.0 compiler release. I’ll try to post when that becomes available.

[Martyn_C_Intel]

I have confirmed that your original test case runs correctly with the released version 16 compiler, a component of Intel Parallel Studio XE 2016, now available at https://registrationcenter.intel.com with current support. If you should see any further problems, please set us know.