(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?
PS: Regtesting fails for continuation_6.f but that's PR fortran/91253
(fails to show a warning when a newer GLIBC is used). And for
gfortran.dg/vect/vect-8.f90 fails because 23 instead of 22 loops get
vectorized - probably someone (richi?) didn't update the expected value.