https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101899
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
>From the gimple dump:
#pragma omp taskloop firstprivate(D.3968) private(i) firstprivate(offset.2) \
firstprivate(stride.1) firstprivate(a.0)
and omplower shows:
.omp_data_o.8.a.0 = a.0;
#pragma omp taskloop ...
a.0 = &.omp_data_i->a.0;
Thus, 'a.0' no longer points to a.0 = a->data – but to the address of
.omp_data_i!
Likewise issue for 'allocatable :: a'. Works with an explicit 'shared(a)'.
* * *
Code wise, in 'omp_default_clause' for ctx->region_type == ORT_TASKLOOP:
7223 kind = lang_hooks.decls.omp_predetermined_sharing (decl);
-> OMP_CLAUSE_DEFAULT_UNSPECIFIED
...
7238 switch (default_kind)
...
7296 if (TREE_CODE (decl) == PARM_DECL
7297 || (!is_global_var (decl)
7298 && DECL_CONTEXT (decl) == current_function_decl))
7299 flags |= GOVD_FIRSTPRIVATE;
...
* * *
For:
!$omp parallel
!$omp master
!$omp taskloop !shared(a)
There is:
#pragma omp taskloop ... firstprivate(stride.1) shared(a.0)
I think we run into the following rule (OMP 5.1, 2.21.1.1 Variables Referenced
in a Construct):
Rules for variables with implicitly determined data-sharing attributes are as
follows:
...
• In a parallel construct, if no default clause is present, these variables are
shared.
...
vvvvvv Fortran vvvvv
• In an orphaned task generating construct, if no default clause is present,
dummy arguments are firstprivate.
^^^^^^ Fortran ^^^^^^
• 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 and
that in the enclosing context is determined to be shared by all implicit tasks
bound to the current team is shared.
• 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.
Additional restrictions on the variables for which data-sharing attributes
cannot be implicitly determined in a task generating construct are described in
Section 2.21.4.4.
Still,
a.0 = &.omp_data_i->a.0;
is odd!
