https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103416
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> --- (In reply to Chung-Lin Tang from comment #1) > Can you see if adding this patch: > https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583279.html > fixes this problem? If so, then it should be another occurrence of PR90030 Yes and no. That patch FIXES the issue libgomp: cuCtxSynchronize error: misaligned address libgomp: cuMemFree_v2 error: misaligned address libgomp: device finalization failed BUT I still see #pragma omp target map(to:D.4246 [len: 4][implicit]) ... and when adding an explicit firstprivate(n) I see #pragma omp target firstprivate(n) map(to:D.4246 [len: 4][implicit]) ... which looks wrong. I understand that implicit mapping tries to solve the problem of explicitly mapping an array section via 'omp target (enter) data' - and then implicitly mapping the whole array. — But I think it does not make sense to add this implicit mapping if there is an implicit or explicit 'firstprivate' for that variable. – That's just generates pointless code, obfuscates the dump, adds an overhead to libgomp, ... Actually, it does not only apply to 'firstprivate' - the same also can be caused for 'tofrom' vs. 'to' as in #pragma omp target ... map(to:D.4217 [len: 4][implicit]) map(tofrom:n [len: 4][implicit]) for the following code: PROGRAM target_parallel_do implicit none INTEGER :: i0, N COMPLEX(8) :: scalar N = 1 !$OMP TARGET PARALLEL do map(from: scalar) private(i0) defaultmap(tofrom) DO i0 = 1, N scalar%re = n END DO !$omp end target parallel do END PROGRAM target_parallel_do Admittedly, I have not yet managed to construct something which causes an observable misbehavior.
