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.