[Openmp-dev] Variant of Example 15.3c from Openmp 4.5 spec examples

[Joachim Protze via Openmp-dev]

Hi Simone,

first I could not find the example you referenced.

Are you talking about this document?
https://www.openmp.org/wp-content/uploads/openmp-examples-4.5.0.pdf


After some tests together with Jonas, we found that clang makes variable 
shared instead of firstprivate as suggested by the specification of 
"implicitly determined data-sharing attributes":


 > In a task generating construct, if no default clause is present, a
 > variable for which the data-sharing attribute is not determined by the
 > rules above is firstprivate.

clang 7.0 shows the same behavior.

Compiling with gcc + icc does not result in an issue.



The behavior is also broken for private variables that have definitely 
no dynamic storage duration (just to exclude that the pointer is the 
problem):

int main() {

#pragma omp parallel num_threads(NUM_THREADS)
   {
     int P = omp_get_thread_num();
     printf("%d: %d\n", omp_get_thread_num(), P);

#pragma omp task
     {
#pragma omp critical
       {
         printf("%d: %d\n", omp_get_thread_num(), P);
         P += 10;
       }
     }
#pragma omp barrier
     printf("%d: %d\n", omp_get_thread_num(), P);
   }
}


For firstprivate, the change of P should have no effect outside of the task.


This seems to be a codegen problem.
Can you file a bugreport?


Best
Joachim


On 10/24/18 1:19 AM, Simone Atzeni via Openmp-dev wrote:
> HI all,
> 
> I  am experiencing a seg fault with a program similar to the one 
> mentioned in the subject.
> 
> My program looks like the following (I am using clang 6.0.):
> 
> ------------------------------------------------------------------------------------------------------------------------
> 
>      int NUM_THREADS = 2;
> 
>      int i;
> 
>      int N[NUM_THREADS];
> 
>      int *P;
> 
> #pragma omp parallel private(P) num_threads(NUM_THREADS)
> 
>      {
> 
>          P = &N[omp_get_thread_num()];
> 
>          // P is firstprivate by default
> 
> #pragma omp task
> 
>              {
> 
> #pragma omp critical
> 
>                  {
> 
>                      printf("%d\n", *P);
> 
>                      printf("%d: %p\n", omp_get_thread_num(), P);
> 
>                  }
> 
>              }
> 
>          }
> 
> ------------------------------------------------------------------------------------------------------------------------
> 
> The difference from the original program is the task construct is not 
> inside a single construct.
> 
> According to the comment in the original example, P is expected to be 
> firstprivate.
> 
> However, my example fails with seg faults because P is not a valid 
> pointer inside the task, while if I add explicitly “firstprivate(P)” or 
> an explicit barrier at the end of the task construct the testcase runs 
> as expected.
> 
> I am wondering whether it is valid or not to have a task construct 
> without being inside a single construct. If it is valid, looks like the 
> default “firstprivate” behavior is not actually happening.
> 
> In my example, it looks like that all threads are spawning a task but 
> once they reach the implicit barrier at the end of the parallel region 
> their stack is not valid anymore, but the task gets executed by the same 
> threads and the pointer P is garbage at that point. If I put the task 
> inside a single construct the program runs correctly.
> 
> Thanks.
> 
> Simone
> 
> ------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and 
> may contain confidential information.  Any unauthorized review, use, 
> disclosure or distribution is prohibited.  If you are not the intended 
> recipient, please contact the sender by reply email and destroy all 
> copies of the original message.
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>