From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3467B3858C53; Fri, 13 Oct 2023 08:45:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3467B3858C53 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1697186754; bh=zpKQz/EqTsehx+OoxP8nhPCJBEM2Eo0pczus+aHQc3g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=rl/fEox6ggfYdHGu+9q6XRtFkTKkX9q0DSSnSn8kXk8yZMDtqnXS+i0kP1+QzlZse un1GOYa23lqMhkBC/GuiThFsdjjcuRioWaVsfaoMBPMu3OT033rMC90Ue3WRCtL4W5 LoOJ+G3c7m7vxpq1LtDWljFadlpMgqPmyt16pzMw= From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/111661] [OpenACC] Detach+Attach of DT component gives libgomp: [0x405140,96] is not mapped when running 'acc update' on DT var itself Date: Fri, 13 Oct 2023 08:45:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: openacc X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111661 --- Comment #2 from Tobias Burnus --- @Patrick: It seems to work fine without "finalize". Can you check whether the big program then works for you? Usually, one should be able to do proper ref counting such that a 'finalize' -> force setting refcounts to zero shouldn't be needed. * * * Looking at the code more closely, the problem is: #pragma omp target oacc_exit_data map(delete:tab.val.data [len: 88]) this tries to 'delete' the array descriptor - but as tab.val.data is part of 'tab', this deletes all of "tab". Compare the C example: struct t { int *a; int n; }; void f() { struct t s; #pragma acc enter data copyin(s.a[:s.n]) #pragma acc exit data delete(s.a[:s.n]) // for completeness, not relevant here: #pragma acc exit data detach(s.a) #pragma acc exit data delete(s.a) } GCC does: #pragma omp target oacc_enter_data map(struct:s [len: 1]) \ map(alloc:s.a [len: 8]) map(to:*_4 [len: _3]) map(attach:s.a [bias: 0]) #pragma omp target oacc_exit_data map(release:s.a [len: 8]) \ map(release:*_8 [len: _7]) map(detach:s.a [bias: 0]) #pragma omp target oacc_exit_data map(detach:s.a [bias: 0]) #pragma omp target oacc_exit_data map(release:s.a [len: 8]) which seems to be at least consistent. Again, here a 'finalize' would force= the reference counts to zero and, hence, also delete 's' and not only the pointee/pointer target *s.a / s.a[0:.n] but also the pointer 's.a' itself. (BTW: Same result since GCC 10; GCC 9 rejects that code.) * * * QUESTION: Is the current code for C (and Fortran) correct according to the OpenACC specification or not? FOLLOW UP QUESTION: If GCC's result is incorrect, what should the compiler = do instead? And if it is correct, the question is: why do both ftn and nvfortran work in the same way?=