Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

combined target teams implements shared clause as firstprivate #39225

Open Quuxplusone opened 5 years ago

Quuxplusone commented 5 years ago
Bugzilla Link PR40253
Status REOPENED
Importance P normal
Reported by Joel E. Denny (jdenny.ornl@gmail.com)
Reported on 2019-01-08 09:01:15 -0800
Last modified on 2020-05-06 15:05:32 -0700
Version unspecified
Hardware PC Linux
CC a.bataev@hotmail.com, Gheorghe-Teod.Bercea@ibm.com, hfinkel@anl.gov, htobonm@eafit.edu.co, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

Clang implements shared(n) on omp target teams as firstprivate instead of shared. For example, n is not shared in the following example:

$ cat test.c
#include <omp.h>
#include <stdio.h>
int main() {
  int n = 0;
  #pragma omp target teams shared(n) num_teams(2)
  #pragma omp parallel num_threads(1)
  {
    #pragma omp atomic update
    ++n;
    printf("n=%d, team=%d\n", n, omp_get_team_num());
  }
  return 0;
}

$ clang -fopenmp test.c && ./a.out
n=1, team=0
n=1, team=1

However, if I split the target teams directive into two directives, I see results indicating n is shared:

$ cat test.c
#include <omp.h>
#include <stdio.h>
int main() {
  int n = 0;
  #pragma omp target 
  #pragma omp teams shared(n) num_teams(2)
  #pragma omp parallel num_threads(1)
  {
    #pragma omp atomic update
    ++n;
    printf("n=%d, team=%d\n", n, omp_get_team_num());
  }
  return 0;
}

$ clang -fopenmp test.c && ./a.out
n=1, team=0
n=2, team=1

The LLVM IR shows that n is passed to the teams by value in the first case and by pointer in the second.

This bugzilla was suggested at:

https://reviews.llvm.org/D56113#1345047

Quuxplusone commented 4 years ago

It was already fixed.

_This bug has been marked as a duplicate of bug 43175_

Quuxplusone commented 4 years ago

The reproducer I reported here still reproduces the bug for me at fbaf835c5c51.

Quuxplusone commented 4 years ago
(In reply to Joel E. Denny from comment #2)
> The reproducer I reported here still reproduces the bug for me at
> fbaf835c5c51.

Oops, marked the wrong bug as a duplicate, thanks for reopening.