https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104696
Bug ID: 104696
Summary: [12 Regression][OpenMP] Implicit mapping breaks struct
mapping
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: cltang at gcc dot gnu.org, jakub at gcc dot gnu.org
Target Milestone: ---
Created attachment 52519
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52519&action=edit
implicit.f90 - compile with -fopenmp and run with a non-shared-memory device.
In my understanding, the following is valid and should work.
However, it fails – and I bet it is due to the implicit mapping of 'var3'. The
code uses:
!$omp target map(to: var3%R(2)%d)
...
Printing on the host the 'loc (var3%R(2)%d)' shows:
21516C0
7F51E5E001D8
STOP 11
As var%R(2)%d (or in the dump 'var3.r[1].d.data') is now in device address
space,
accessing it after the target region crashes the program.
implicit.f90.005t.original:
#pragma omp target
map(to:var3.r[1].d [len: 88])
map(to:*(struct t2[0:] *) var3.r[1].d.data [len: D.4243 * 4])
map(always_pointer:(struct t2[0:] *) var3.r[1].d.data [pointer assign,
bias: 0])
implicit.f90.006t.gimple:
#pragma omp target num_teams(1) thread_limit(0)
map(tofrom:var3 [len: 440][implicit])
map(to:var3.r[1].d [len: 88])
map(to:MEM <struct t2[0:]> [(struct t2[0:] *)_9] [len: _8])
map(always_pointer:var3.r[1].d.data [pointer assign, bias: 0])
