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.