https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70895
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |ASSIGNED CC| |cltang at gcc dot gnu.org Component|fortran |middle-end Assignee|tschwinge at gcc dot gnu.org |cltang at gcc dot gnu.org --- Comment #5 from Thomas Schwinge <tschwinge at gcc dot gnu.org> --- We've gotten that aspect of the OpenACC specification clarified as follows (comments inside parens are mine): "A scalar variable referenced in a parallel construct without predetermined (already implemented) or explicitly determined data attributes (already implemented) will have its data attributes implicitly determined as described in this paragraph. If the scalar variable appears in a reduction clause on the parallel construct (already implemented), or in a reduction clause on a loop construct in the parallel construct (relevant for this PR70895), or is assigned in an atomic construct in the parallel construct (another change), the scalar variable is treated as if it appeared in a copy clause for the parallel construct. In all other cases, the scalar variable is treated as if it appeared in a firstprivate clause for the parallel construct (already implemented)." Chung-Lin, please sanity-check that this will make work Ralph's example program as attached, and then implement these semantics for trunk, gcc-6-branch, gomp-4_0-branch (gcc/gimplify.c; hopefully the same patch will do for all three branches; please shout if not). In addition to Ralph's example program as attached, also add ample testsuite coverage, for various nesting of OpenACC constructs, for all of C, C++, and Fortran. If the change is non-trivial to detect that a "scalar variable [...] is assigned in an atomic construct" ("another change" above), please leave that aspect aside for the moment.