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

[Simone Atzeni via Openmp-dev]

Hi Joachim.

Sorry the document was the 4.0 not the 4.5. Anyway, my example was a variant of the example 15.3c.

Thanks you for confirming, I was able to make it work only with gcc and icc as well.
I'll file a bug report.

Thanks!
Simone

-----Original Message-----
From: Joachim Protze <protze.joachim at gmail.com> 
Sent: Wednesday, October 24, 2018 4:44 AM
To: Simone Atzeni <satzeni at nvidia.com>; openmp-dev at lists.llvm.org
Subject: Re: [Openmp-dev] Variant of Example 15.3c from Openmp 4.5 spec examples

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
>