https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80029
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |cesar at gcc dot gnu.org,
| |tschwinge at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That doesn't work, it is too early.
With:
--- gimplify.c.jj 2017-03-08 18:19:24.000000000 +0100
+++ gimplify.c 2017-03-20 07:22:05.587913531 +0100
@@ -9261,6 +9261,8 @@ gimplify_oacc_declare (tree *expr_p, gim
omp_add_variable (gimplify_omp_ctxp, decl, GOVD_SEEN);
}
+ gimplify_adjust_omp_clauses (pre_p, NULL, &clauses, OACC_DECLARE);
+
stmt = gimple_build_omp_target (NULL, GF_OMP_TARGET_KIND_OACC_DECLARE,
clauses);
we don't ICE on it, but still no idea what is the right thing to do.
>From what I understand, #pragma acc declare is active for all code from the
directive till end of function (unless the variables mentioned in its clauses
go out of scope earlier), so in theory perhaps the right thing is to move the
gimplify omp context structure up in the gimplify context tree so that they are
just children of the function (what happens if you put #pragma acc declare
inside
the body of some other acc region?).
Though on the other side, e.g. for #pragma omp target enter data we adjust the
omp clauses right away, but that doesn't really affect the handling of
variables later on. So, the important question is do you need the variables
mentioned in acc declare clauses to be in the hash tables as GOMP_MAP after
gimplify_oacc_declare returns or not? If not, then the above patch might DTRT,
otherwise we need to figure out something different.
