https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90743
Bug ID: 90743
Summary: Device-side 'malloc' for Fortran 'allocatable' scalar
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: openacc, openmp
Severity: enhancement
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
As '-fdump-tree-original' shows, for:
program main
implicit none
integer, allocatable :: c
allocate (c)
c = 25
!$omp target map(from: c)
!$acc parallel copyout(c)
c = 52
!$acc end parallel
!$omp end target
if (c /= 52) stop 2
deallocate (c)
end program main
... we currently generate code as follows:
[...]
*c = 25;
#pragma omp target map(from:*c) map(alloc:c [pointer assign, bias: 0])
{
{
{
if (c != 0B) goto L.3;
c = (integer(kind=4) *) __builtin_malloc (4);
L.3:;
*c = 52;
}
}
}
[...]
Same for OpenACC.
At least in the case of nvptx offloading that I just tried, we're not actually
executing that 'malloc' on the device. Will this always be the case? Could
code generation then be changed to turn this into an 'abort', to make this less
surprising for the human reader?
---
I just saw Jakub's Comment 1 in PR90741, so I suppose the 'c = 52' assignment
is where this device-side 'malloc' is coming from.
