[Bug libgomp/92503] [OpenACC] Behavior of 'acc_free' if the memory space is still used in a mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92503 --- Comment #4 from Thomas Schwinge --- Author: tschwinge Date: Mon Dec 9 22:52:47 2019 New Revision: 279146 URL: https://gcc.gnu.org/viewcvs?rev=279146=gcc=rev Log: [PR92503] [OpenACC] Don't silently 'acc_unmap_data' in 'acc_free' libgomp/ PR libgomp/92503 * oacc-mem.c (acc_free): Error out instead of 'acc_unmap_data'. * testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-1.c: New file. * testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-3-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-3.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/clauses-1.c: Adjust. * testsuite/libgomp.oacc-c-c++-common/context-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/context-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/context-3.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/context-4.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-13.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-14.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-18.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-91.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/nested-1.c: Likewise. Added: trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-1.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-2.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-3-2.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-3.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4-2.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_free-pr92503-4.c Modified: trunk/libgomp/ChangeLog trunk/libgomp/oacc-mem.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-1.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/context-1.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/context-2.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/context-3.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/context-4.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-13.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-14.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-18.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-91.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/nested-1.c
[Bug libgomp/92503] [OpenACC] Behavior of 'acc_free' if the memory space is still used in a mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92503 Thomas Schwinge changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-12-09 Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Thomas Schwinge --- (In reply to myself from comment #2) > 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. This is a variant of PR92877. ;-O > Please also verify whether there are any changes necessary for AMD GCN > offloading, in particular un-XFAILing the two nvptx ones, I suppose? ..., so not related to nvptx offloading.
[Bug libgomp/92503] [OpenACC] Behavior of 'acc_free' if the memory space is still used in a mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92503 --- Comment #2 from Thomas Schwinge --- Created attachment 47445 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47445=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.
[Bug libgomp/92503] [OpenACC] Behavior of 'acc_free' if the memory space is still used in a mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92503 --- Comment #1 from jules at gcc dot gnu.org --- FWIW, I don't think we should do this implicit unmapping, particularly since it implies an expensive device-to-host-address lookup.
