[Bug middle-end/70895] OpenACC: loop reduction does not work. Output is zero.

["tschwinge at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.