https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80029
--- Comment #3 from cesar at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #2) > 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?). You are correctly describing the behavior of declare in OpenACC. Declared variables live throughout the scope specified by the user. However, I believe the scope must be global or function, i.e. I don't think you can declare variables inside nested blocks in C/C++. > 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. I don't think this memory leak is present in gomp-4_0-branch. The patch that resolves this issue was posted back in September 2016 here <https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01630.html>. I'll rebuild trunk with that patch to see if it resolves the memory leak there.
