[Bug libgomp/92843] [OpenACC] Disallow 'acc_delete' etc. for everything without a dynamic reference count

[jules at gcc dot gnu.org]

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

--- Comment #9 from jules at gcc dot gnu.org ---
FWIW, I wrote this at the time wrt. the refcounting changes (some parts refer
to a previous iteration of the manual deep copy patches)...

Writing a couple of new attach/detach tests, I realised that reference
counting for OpenACC was pretty seriously broken. In an attempt to fix
that, I've:

 - written self-checking code to verify reference counts. This walks
   over the whole memory-mapping splay tree and re-counts references,
   making sure they match up with the running tallies kept by the
   mapping/unmapping routines.

 - removed the dubious "finalize" arguments from the unmap routines you
   pointed out. Call "detach" in more appropriate places.

 - rewritten gomp_acc_{insert,remove}_pointer, and change the way
   "enter data" mapping works in OpenACC to be more like the
   implementation for OpenMP (gomp_acc_remove_pointer is now modelled
   on target.c:gomp_exit_data).

 - ...which means we can get rid of the "acc_dev->openacc.data_environ"
   list. I think I added that to start with (ICBW!) but now I don't
   think we need it. That means we avoid a lot of scanning through
   linear linked lists to find the "right" target_mem_desc to unmap --
   which it turns out was buggy, and also probably conceptually wrong.
   (In GOACC_enter_exit_data, that meant each mapping clause got its own
   "target_mem_desc" when entering, which isn't how things normally work
   for gomp_map_vars. That meant that when "exit data"ing, again
   individual clauses could remove the corresponding target_mem_desc.
   What *didn't* work is if the mappings for a single target_mem_desc
   returned by GOACC_enter_exit_data refer to *other* target_mem_descs
   in their argument lists, rather than pointing back to the same one. A
   lot of the code that was checking "t->refcount" for "2" or "minrefs"
   in oacc-mem.c was simply broken.)

 - lookup_dev scans over the splay tree instead of looking through the
   data_environ list. It should have done that to start with -- it
   means it'll be able to find data mapped inside "pragma acc data"
   blocks, which it wouldn't have been able to previously.

It's a lot of changes, but (I hope!) with the RC_CHECKING feature we'll
be able to be a little more confident that we've got the memory map
refcounting right, at least.