[Bug fortran/90743] Fortran 'allocatable' in OpenACC/OpenMP target offloading regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90743 Thomas Schwinge changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from Thomas Schwinge --- (In reply to Dominique d'Humieres from comment #4) > Is this PR valid or not? Yes. More test cases are needed, and code changes, too, to support other clauses.
[Bug fortran/90743] Fortran 'allocatable' in OpenACC/OpenMP target offloading regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90743 --- Comment #5 from Thomas Schwinge --- Author: tschwinge Date: Tue Jun 18 22:14:24 2019 New Revision: 272447 URL: https://gcc.gnu.org/viewcvs?rev=272447&root=gcc&view=rev Log: [PR90743] Fortran 'allocatable' with OpenACC data/OpenMP 'target' 'map' clauses Test what OpenMP 5.0 has to say on this topic. And, do the same for OpenACC. libgomp/ PR fortran/90743 * oacc-parallel.c (GOACC_parallel_keyed): Handle NULL mapping case. * testsuite/libgomp.fortran/target-allocatable-1-1.f90: New file. * testsuite/libgomp.fortran/target-allocatable-1-2.f90: Likewise. * testsuite/libgomp.oacc-fortran/allocatable-1-1.f90: Likewise. * testsuite/libgomp.oacc-fortran/allocatable-1-2.f90: Likewise. Added: trunk/libgomp/testsuite/libgomp.fortran/target-allocatable-1-1.f90 trunk/libgomp/testsuite/libgomp.fortran/target-allocatable-1-2.f90 trunk/libgomp/testsuite/libgomp.oacc-fortran/allocatable-1-1.f90 trunk/libgomp/testsuite/libgomp.oacc-fortran/allocatable-1-2.f90 Modified: trunk/libgomp/ChangeLog trunk/libgomp/oacc-parallel.c
[Bug fortran/90743] Fortran 'allocatable' in OpenACC/OpenMP target offloading regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90743 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |WAITING Last reconfirmed||2019-06-09 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Is this PR valid or not?
[Bug fortran/90743] Fortran 'allocatable' in OpenACC/OpenMP target offloading regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90743 --- Comment #3 from Jakub Jelinek --- (In reply to Thomas Schwinge from comment #2) > Thanks for your comment; I wasn't aware of the (default) '-frealloc-lhs' > behavior (PR90741), and indeed that's supported inside offloading regions, > too. > > (In reply to Jakub Jelinek from comment #1) > > The code in the region could deallocate (c) or > > do similar stuff, and while that might be undefined with some offloading > > specs under some conditions, there are many cases where it must be valid. > > Indeed that's not permitted per my reading of OpenMP 5.0 -- but it does seem > to work in the GCC implementation, inside an offloading region to > 'deallocate' and then re-'allocate', which seems to make the device object > "detached" from the host object. Is that something we should thus be > testing (with a comment: "implementation-defined behavior"), or should we > not test such things? It is undefined behavior, so we shouldn't be testing it.
[Bug fortran/90743] Fortran 'allocatable' in OpenACC/OpenMP target offloading regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90743 Thomas Schwinge changed: What|Removed |Added Summary|Device-side 'malloc' for|Fortran 'allocatable' in |Fortran 'allocatable' |OpenACC/OpenMP target |scalar |offloading regions --- Comment #2 from Thomas Schwinge --- Thanks for your comment; I wasn't aware of the (default) '-frealloc-lhs' behavior (PR90741), and indeed that's supported inside offloading regions, too. (In reply to Jakub Jelinek from comment #1) > The code in the region could deallocate (c) or > do similar stuff, and while that might be undefined with some offloading > specs under some conditions, there are many cases where it must be valid. Indeed that's not permitted per my reading of OpenMP 5.0 -- but it does seem to work in the GCC implementation, inside an offloading region to 'deallocate' and then re-'allocate', which seems to make the device object "detached" from the host object. Is that something we should thus be testing (with a comment: "implementation-defined behavior"), or should we not test such things?
