[Bug libgomp/103276] [openacc] Trying to map already mapped data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103276 --- Comment #5 from Yury Gribov --- Created attachment 51823 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51823=edit Runnable reprocase I've attached another reprocase which reproduces the error at runtime (but let me reiterate that the original minirepro is easier to analyze). It can be compiled with /home/y.gribov/install/gcc-master/usr/local/bin/gfortran repro.f90 -O2 -ffree-form -fopenacc -foffload-options=-march=gfx908 It crashes at runtime with libgomp: Trying to map into device [0x7fffd8d0..0x7fffd928) object when [0x7fffd918..0x7fffd920) is already mapped Problem reproduces both on devel/omp/gcc-11 (commit f85ed229, Nov 10) and master (commit 0136f25a, Nov 10).
[Bug libgomp/103276] [openacc] Trying to map already mapped data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103276
--- Comment #4 from Yury Gribov ---
(In reply to Andrew Pinski from comment #3)
> No the gimple is wrong. is taking the address of the argument. It
> should just be var here if you what the reference points to rather than the
> address of the decl holding the pointer.
Thank you, makes sense. In that case the problem occurs at OMP lowering:
voidD.27 copyin_simple (struct simple & restrict varD.3961)
{
var.0_1 = varD.3961;
{
D.3965.D.3963 = var.0_1;
D.3965.varD.3964 =
#pragma omp target oacc_enter_exit_data map(to:*var.0_1 [len: 8])
map(alloc:varD.3961 [pointer assign, bias: 0])
[Bug libgomp/103276] [openacc] Trying to map already mapped data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103276
--- Comment #3 from Andrew Pinski ---
(In reply to Yuri Gribov from comment #0)
> Here hostaddrs[1] points to a spurious variable in current stack frame.
>
> Gimple code seems to be correct
> voidD.27 copyin_simple (struct simple & restrict varD.3961)
> {
> struct .omp_data_t.1D.3962 D.3965;
> ...
> # .MEM_4 = VDEF <.MEM_3>
> D.3965.varD.3964 =
No the gimple is wrong. is taking the address of the argument. It should
just be var here if you what the reference points to rather than the address of
the decl holding the pointer.
[Bug libgomp/103276] [openacc] Trying to map already mapped data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103276 Yury Gribov changed: What|Removed |Added CC||ygribov at gcc dot gnu.org --- Comment #2 from Yury Gribov --- This might be by chance, it could be fixed in mainline - or your example is too much simplified. > At least as is it cannot fail as there is no main program but just a module. I see. But is a runtime crash really mandatory here? It requires a bit of luck so that address ranges of local variable in copyin_simple overlaps local variables in another call. And even if it does, the crash will not be very stable across branches (because stack layouts change, etc.). My main goal was to provide a minimal self-explanatory usecase - there is a clear reference to local stack object passed to GOACC_enter_exit_data which is missing in the original code...
[Bug libgomp/103276] [openacc] Trying to map already mapped data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103276 Tobias Burnus changed: What|Removed |Added Keywords||openacc --- Comment #1 from Tobias Burnus --- I only have GCC mainline at hand - and there it did not fail when adding: use REPRO type(simple) :: var call COPYIN_SIMPLE(var) end This might be by chance, it could be fixed in mainline - or your example is too much simplified. At least as is it cannot fail as there is no main program but just a module. I think a complete example would help. Or you confirm that it will fail as shown after adding the 4 lines above...
