[Bug libgomp/93305] New: [OpenACC] 'acc_shutdown' vs. active data lifetimes

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93305

            Bug ID: 93305
           Summary: [OpenACC] 'acc_shutdown' vs. active data lifetimes
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Keywords: openacc
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tschwinge at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
        Depends on: 65904, 88981, 88941
  Target Milestone: ---

We need to better lay out and document how we handle 'acc_shutdown' vs. active
data lifetimes: for example, due to 'async' still running, due to OpenACC
'declare', due to OpenACC 'data' construct, due to OpenACC 'enter data' without
'exit data'.

Likewise for an implicit "shutdown" at process termination.

It seems clear that 'acc_shutdown' should immediately unmap/deallocate
everything.

It's less clear what should happen when after an 'acc_shutdown' we then again
(implicitly/explicitly) 'acc_init': how/which state gets restored?

It seems wrong that we currently make it a runtime error when "shutdown in 'acc
data' region".  (The diagnostic got added in gomp-4_0-branch r216925
"Rationalise thread-local variables in libgomp OpenACC support"; unclear what
the behavior was before.)

It's not clear what after an 'acc_shutdown' should happen in the "exit"
handling of a structured data region;
<https://github.com/OpenACC/openacc-spec/issues/257>.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65904
[Bug 65904] Memory corruption with acc_shutdown, nvptx offloading,
libgomp.oacc-c-c++-common/asyncwait-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88941
[Bug 88941] [nvptx, openacc, libgomp] Assertion `!s->map->active' failed for
empty asynchronous parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88981
[Bug 88981] [nvptx, openacc, libgomp] How to handle async regions without
corresponding wait