https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2019-12-06
See Also| |https://github.com/OpenACC/
| |openacc-spec/issues/246
Assignee|unassigned at gcc dot gnu.org |jules at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Julian, please verify the following against your understanding of OpenACC 2.6
semantics.
I had assumed that that 'acc_delete'/'#pragma acc exit data delete'/etc. should
not be permitted on '#pragma acc declare'd data, and should not be permitted
after 'acc_map_data'. (Which in GCC are those using REFCOUNT_INFINITY', so
that's easy to detect.)
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!
}
