On Fri, Sep 20, 2019 at 05:47:59PM +0200, Tobias Burnus wrote:
> This patch does two things:
>
> (A) For OpenACC, only, it fixes the is-variable check. That check missed to
> reject module names (as noted in the PR) but as my testing showed, it also
> wrongly rejected function-result variables. (i.e. where the return-value
> variable has the same name as the function). - For the invalid input of the
> PR, gfortran gave an ICE in the gimplifier.
>
> (B) Using such function-result variables did not work properly. OpenACC used
> in both cases (see pr78260-2.f90) the function name – and at least one
> variant failed with an ICE.
>
> OpenMP used the result variable for "target data map" but not for "target
> update". Additionally "task depend" had the same issue.
>
>
> Bootstrapped and regtested on x86_64-gnu-linux w/o accelerator.
>
> I intent to build/regtest it also applied to the OG9 (openacc-gnu-9) branch
> and run the test case with actual nvptx+AMDGCN offloading, but I have not
> done so, yet.
>
> OK for the trunk?
LGTM, thanks.
I'm not entirely sure about the detailed #pragma matches in the dumps, if
they turn out to be too hard to maintain, we can always remove those or
adjust so that they match with fewer details.
> 2019-09-20 Tobias Burnus <tob...@codesourcery.com>
>
> PR fortran/78260
> * openmp.c (gfc_resolve_oacc_declare): Reject all
> non variables but accept function result variables.
> * trans-openmp.c (gfc_trans_omp_clauses): Handle
> function-result variables for remaing cases.
>
> 2019-09-20 Tobias Burnus <tob...@codesourcery.com>
>
> PR fortran/78260
> * gfortran.dg/goacc/parameter.f95: Change
> dg-error as it is now detected earlier.
> * gfortran.dg/goacc/pr85701.f90: Modify to
> use a separate result variable.
> * gfortran.dg/goacc/pr78260.f90: New.
> * gfortran.dg/goacc/pr78260-2.f90: New.
> * gfortran.dg/gomp/pr78260.f90: New.
> * gfortran.dg/gomp/pr78260-2.f90: New.
> * gfortran.dg/gomp/pr78260-3.f90: New.
Jakub
