[Bug libgomp/92503] [OpenACC] Behavior of 'acc_free' if the memory space is still used in a mapping

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Created attachment 47445
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47445&action=edit
[PR92503] [OpenACC] Don't silently 'acc_unmap_data' in 'acc_free'

(In reply to jules from comment #1)
> FWIW, I don't think we should do this implicit unmapping

Julian, please have a look at the patch I'm attaching.

There are nvptx offloading TODOs in
'libgomp.oacc-c-c++-common/acc_free-pr92503-4.c',
'libgomp.oacc-c-c++-common/acc_free-pr92503-4-2.c'.  Can you easily (please
don't spend much time on this) what's going wrong?  Otherwise I shall commit
that XFAILed.

Please also verify whether there are any changes necessary for AMD GCN
offloading, in particular un-XFAILing the two nvptx ones, I suppose?


> particularly since
> it implies an expensive device-to-host-address lookup.

ACK.  That's not yet done; let's first wait what OpenACC is going to require.

I had the idea that we might actually keep such additional/expensive
sanity-checking, but guard it by an environment variable.