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

Simone Atzeni via Openmp-dev openmp-dev at lists.llvm.org
Tue Oct 23 16:19:02 PDT 2018

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.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20181023/6f798812/attachment.html>

More information about the Openmp-dev mailing list