[Bug middle-end/70828] broken array-type subarrays inside acc data in openacc

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70828

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |openmp
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2016-04-28
                 CC|                            |jakub at gcc dot gnu.org
           Assignee|cesar at gcc dot gnu.org           |unassigned at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to cesar from comment #0)
> Created attachment 38351 [details]
> broken subarray

Translating that one to OpenMP ("acc data copy(a[10:80])" -> "omp target data
map(a[10:80])", and "acc parallel loop" -> "omp target"), the issue also
reproduces for OpenMP.

> Given an array-typed subarray with a non-zero base element on an acc data
> construct, the gimplifier will implicitly add a pcopy clause for any
> parallel and kernels construct which uses that array. The pcopy is correct,
> but this pcopy expects the entire array to be present on the accelerator.
> This ultimately results in a runtime failure when the base of the subarray
> is not element zero.
> 
> This problem can be reproduced with the attached test case in trunk and
> gcc-6.

OpenACC 2.0a says that "[...] the compiler will implicitly determine data
attributes for variables that are referenced in the compute construct that do
not appear in a data clause on the compute construct or a lexically containing
data construct and do not have predetermined data attributes [...]".  Indeed we
here have a "lexically containing data construct", so the compiler should use
that instead of implicitly determining conflicting (whole array) data
attributes.

Jakub, what's your take for OpenMP?  From a quick scan of OpenMP 4.5, 2.15.5
"Data-mapping Attribute Rules and Clauses", in combination with 2.10.4 "target
Construct", to me it also appears as if the intention is that the outer target
data construct already defines the definitive data attributes for the array
inside the target region, without wanting the compiler to implicitly determine
conflicting (whole array) data attributes for the target region?