LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 40253 - combined target teams implements shared clause as firstprivate
Summary: combined target teams implements shared clause as firstprivate
Status: REOPENED
Alias: None
Product: OpenMP
Classification: Unclassified
Component: Clang Compiler Support (show other bugs)
Version: unspecified
Hardware: PC Linux
: P normal
Assignee: Unassigned Clang Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-08 09:01 PST by Joel E. Denny
Modified: 2020-05-06 15:05 PDT (History)
5 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joel E. Denny 2019-01-08 09:01:15 PST
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
Comment 1 Alexey Bataev 2019-12-13 13:50:25 PST
It was already fixed.

*** This bug has been marked as a duplicate of bug 43175 ***
Comment 2 Joel E. Denny 2019-12-17 08:58:21 PST
The reproducer I reported here still reproduces the bug for me at fbaf835c5c51.
Comment 3 Alexey Bataev 2019-12-17 09:00:31 PST
(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.