Sharing a private variable with tasks

[Alfredo]

Hello,
consider the case where a single thread (say, the master) has a private vector x and submits a number of tasks which update different coefficients of x. Here is a simple (fortran) code that does this

[fortran]program main

  implicit none

  integer, allocatable :: x(:)

  integer              :: m, j

  m = 10

  !$omp parallel private(x)

  !$omp master

  allocate(x(m))

  do j=1, m

     !$omp task firstprivate(j) shared(x)

     x(j) = j

     !$omp end task

  end do

  !$omp taskwait

  deallocate(x)

  !$omp end master

  !$omp end parallel

  stop

end program main
[/fortran]

I would like to know whether this code is OpenMP compliant and/or correct.
My understanding is that the shared clause in the task construct is such that within the task the actual x array is the one that was allocated by the master, regardless of the thread executing the task. Is this correct?

This code does not work with intel ifort. The compiler complains about x not being allocated (if I turn on the compiler bounds check whistles). If I remove the deallocate statement then the code works ok but because of the taskwait, the deallocation should not be executed before all the tasks are done and thus this behavior seems totally strange to me. Also, the code works fine if I make x a pointer instead of an allocatable.

The code works fine with gfortran.

Is this an ifort bug?

Kind regards,
alfredo

[Alfredo]

I should have mentioned in the title that this is OpenMP problem. Sorry about that
 

[pbkenned1]

Hello Alfredo,

Very interesting...thanks for submitting the issue.  I don't see that the code is non-compliant with the OpenMP standard.  You are correct that the task shared(x) is the same one as allocated by the master thread.

I think the issue you are seeing with ifort is really just due to '-check bounds', not really a bug in our OpenMP implementation.  I can only make the code fail if I compile with bounds checking.

I think the problem is because you declared x to be private at the start of the parallel region.  Array x has the allocatable attribute, but is unallocated at the start of the parallel region.  Thus, a private x is created for each thread in the team, including the master, but all inherit the unallocated status.  Next, the master thread allocates its instance, but the remaining instances of x owned by the worker threads remain unallocated.

So, I think the real problem is that the bounds checking logic is testing the bounds of the unallocated instances of x owned by the worker threads.  The problem is that there is no way for that logic to know those instances are unallocated.  That is something that we probably cannot fix, but I will check with the developers.

If you change x to be shared at the start of the parallel region, ie '!$omp parallel shared(x)', then I see no runtime issues, when I compile with '-check bounds'.  One and only one instance of x is created, it is then allocated, and everything works as expected.

Regards,

Patrick

[Alfredo]

Patrick,

thanks a lot for clearing this issue. With ifort 14.0.0 and 12.0.0 I could actually reproduce what you observed (failure with runtime checks and no failure without). With 13.1.1 I still see a segfault when compiled without runtime checks.

Kind regards,

Alfredo

[pbkenned1]

Hell Alfredo,

Thanks for the valuable feedback that you've seen the problem with ifort-13.1.1 *without* compiling for runtime checks.  I observe the same thing with your test case.

That suggests to me there may be an underlying bug that just happens to be exposed by bounds checking in ifort-14.0.  I am further convinced of a possible bug since if you compile for bounds checking and run the program on one thread (OMP_NUM_THREADS=1), it will crash.  There should not be any unallocated instances of private(x) in the single thread case.

I'll report this to the developers to be on the safe side.  Note that any fix would be applied to ifort-14 or later.

Regards,

Patrick

[Alfredo]

Patrick,

thanks for being so responsive.

Regards,

Alfredo

[pbkenned1]

Hello Alfredo,

You are most welcome, and thanks again for reporting this.  I've reported this to the developers, and I'll keep this thread updated with any news from them.

Tracking ID:  DPD200251029

Best regards,

Patrick

[pbkenned1]

This issue should be fixed in the next 15.0 compiler release (update #1), which is coming soon.  I'll double check when released and confirm.

Patrick

[pbkenned1]

Sorry for the late notice, but I just received a note from the developers that this is fixed in ifort-15.0.1.

[U498463]$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.1.133 Build 20141023
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

[U498463]$ ifort -qopenmp U498463.f90 -o U498463.f90.x
[U498463]$ ./U498463.f90.x
[U498463]$

Closing this ticket now.

Patrick