On Mon, Jul 06, 2015 at 09:45:30PM +0300, Ilya Verbin wrote:
> > What exactly do you have in mind here?
> >
> > void foo (int *p)
> > {
> > #pragma omp enter data (to:p[10])
> > ...
> > #pragma omp exit data (from:p[10])
> > }
> >
> > where the latter will only deallocate &p[0] ... &p[9], but not &p?
> > I've asked for clarification in that case, but if it should deallocate (or
> > decrease the counter) for &p too, then I think this is something for the
> > frontends to handle during handling of array sections in map clause, or
> > during gimplification or omp lowering.
>
> I mean, in enter data map(to:p[10]):
> 1. Map GOMP_MAP_TO var as usual, and save returned target_mem_desc *tgt_var
> into
> last_tgt_var.
> 2. Map GOMP_MAP_POINTER var, and save returned tgt_var->list[0].key into
> last_tgt_var->new_special_field_for_pointer.
>
> And in exit data map(from:p[10]):
> 1. Unmap GOMP_MAP_FROM var as usual, *and* deallocate (or decrease refcount)
> of
> k->tgt->new_special_field_for_pointer.
> 2. Do nothing for GOMP_MAP_POINTER var.
>
> But I don't like this plan, there may be corner cases.
As has been clarified on omp-lang, we actually shouldn't be mapping or
unmapping the pointer and/or reference, only the array slice itself, except
in target construct (and even for that it is changing from mapping to
private + pointer assignment).
Jakub
