https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|jules at gcc dot gnu.org |tschwinge at gcc dot
gnu.org
Summary|[OpenACC] Disallow |[OpenACC] Wrong/missing
|'acc_delete' etc. for |dynamic reference counting
|everything without a |for structured
|dynamic reference count |'REFCOUNT_INFINITY'
--- Comment #10 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to myself from comment #1)
> I had assumed [...]
> But, I'm not sure now, after thinking through the following. ;-\
>
> Because: per my reading, it actually is permissible to call
> 'acc_delete'/etc. (dynamic reference counter; "present decrement" action)
> inside '#pragma acc data' (structured reference counter). This "decrements
> the [...] dynamic reference counter for 'var', if its value is greater than
> zero. If the reference counter is already zero, its value is left
> unchanged". The latter applies here. "If both reference counters are then
> zero, a delete action is performed." The structured reference counter is
> left untouched by 'acc_delete', so the data remains mapped; 'acc_delete'
> actually is a no-op?
>
> #define N 23
> float h[N];
>
> #pragma acc data create(h)
> {
> acc_delete(&h, 92); // no-op
> // 'h' remains mapped!
> }
I read OpenACC 2.6 again, and convince myself that indeed this seems to be the
expected behavior, thus adjusting this PR Summary, and testing adjusted patch.