[flang-commits] [flang] [flang][OpenACC] Reland data-clause designator path handling (PR #220781)

[Eugene Epshteyn via flang-commits]

================
@@ -0,0 +1,45 @@
+! RUN: bbc -fopenacc -emit-hlfir %s -o - | FileCheck %s
+
+! A POINTER member of a COMMON block that is listed together with the whole
+! block is contained in the block and is dropped, as for any other member. The
+! member is then firstprivatized with the bytes of the block, which copies the
+! pointer association, instead of through an operand of its own. The region
+! derives the member from the block operand.
----------------
eugeneepshteyn wrote:

(This comment was generated with the help of AI)

This comment documents the byte-copy as copying the pointer association, but the standalone spelling of the same clause does the opposite, so one of the two lowerings is wrong whichever semantics is intended:

```fortran
subroutine beside_block(v)
  real, target :: v(10)
  real, pointer :: p(:)
  common /blk/ p
  p => v
  !$acc parallel firstprivate(p) firstprivate(/blk/)
  p(1) = 2
  !$acc end parallel
end subroutine

subroutine standalone(v)
  real, target :: v(10)
  real, pointer :: p(:)
  common /blk/ p
  p => v
  !$acc parallel firstprivate(p)
  p(1) = 2
  !$acc end parallel
end subroutine
```

With this revision, `beside_block` lowers `p` through `@firstprivatization_optional_ref_48xi8` (an `hlfir.assign` of the block's raw bytes — the descriptor is copied, so the private `p` aliases the shared target and `p(1) = 2` writes shared storage), while `standalone` lowers `p` through `@firstprivatization_ref_box_ptr_Uxf32` (`fir.allocmem` plus a value copy — a private deep copy of the pointee, and the write stays private).

OpenACC 3.3 2.5.14 says the copy is "initialized with the value of that item", which for a Fortran pointer is arguably its association — but 2.5.13/2.5.14 never address Fortran pointers directly, and 2.7.1's "pointer association is not preserved in device memory" (data-clause text) suggests the raw descriptor bytes are only meaningful on shared memory. @razvanlupusoru @jeanPerier — could you make the call on which semantics `firstprivate` of a Fortran POINTER should have? Whichever way it goes, I'd ask for: a contrast test covering both spellings that associates the pointer and checks the recipe contents (the test here leaves `p` disassociated, so the copied bytes are never observable); this comment amended to acknowledge the standalone spelling differs and the discrete-memory caveat; and a follow-up issue for the losing lowering.

https://github.com/llvm/llvm-project/pull/220781