GPU macros: OpenMP renders `attach` as map(always,tofrom:), which is not what OpenACC's attach means

[sbryngelson]

Bug

In src/common/include/omp_macros.fpp, the dedicated attach generator is commented out:

#! #:def OMP_ATTACH_STR(attach)
#! #:set attach_val = OMP_MAP_STR('always,to', attach)
#! $:attach_val

and the live path in OMP_PARALLEL_LOOP (line 135) renders it differently:

#:set attach_val = OMP_MAP_STR('always,tofrom', attach)

OpenACC's attach only fixes up device pointers within an aggregate that is already present;
it performs no data transfer, and certainly no copy-back. The OpenMP branch emits
map(always,tofrom:), which forces an unconditional host→device and device→host transfer
on every launch.

So the same GPU_PARALLEL_LOOP(..., attach='[...]') call means two different things depending
on backend: a pointer fix-up under OpenACC, a full round-trip copy under OpenMP. Besides the
performance cost, a copy-back can overwrite device-side updates with stale host data.

Suggested fix

Either restore the commented-out generator (always,to, matching the intent), or — closer to
OpenACC semantics — emit no map at all for attach and rely on the aggregate already being
present, since attach is a pointer-attachment operation rather than a data-movement one.

Context

Found during a systematic ACC-vs-OMP differential audit of the macro layer while porting MFC
to CCE 21 on Frontier. Two other divergences of the same shape have already been found in this
layer:

• defaultmap(firstprivate:scalar) emitted unconditionally, which CCE 21 lets override an
  explicit map(to:) (compiler defect, but MFC only exposes it because of this clause)
• no_create accepted by the macro API but #:stop-ed in the OpenMP layer (GPU_PARALLEL_LOOP advertises no_create but OMP_NOCREATE_STR aborts fypp, breaking OpenACC-only builds #1687)

The pattern is that the OpenMP branch does more than the OpenACC branch means. A full audit
of the remaining clauses is worthwhile; the stubs at omp_macros.fpp:36 (default='none'),
:261 and :318 are the other known gaps.

[sbryngelson]

Evidentiary status: code-level finding, no demonstrated runtime failure

Recording this so nobody assumes more evidence exists than actually does.

What this issue rests on. Reading the macro layer: attach renders as
map(always,tofrom:) under OpenMP, while the OpenACC path performs a genuine attach. Those are
not equivalent — one copies data, the other establishes the device-side pointer relationship
between a parent aggregate and its pointee. That discrepancy is real and stands on its own.

What it does not rest on. There is no reproduced wrong answer, fault, or test failure
attributable to it. I attempted to build a standalone reproducer and failed twice:

1. First version did not compile — #ifdef in a lowercase .f90, which ftn will not
   preprocess without -eZ. The captured "results" were build errors.
2. After fixing that, the OpenACC arm reported a failure to attach — which contradicts MFC
   passing its full 627-test suite on --gpu acc using exactly the ACC_SETUP_SFs pattern in
   question. A third round (removing a declare create / enter data double-map, the trap
   documented in our own notes) did not resolve the disagreement.

When a microbenchmark disagrees with a green production suite, the microbenchmark is wrong. The
reproducer has been deleted rather than kept, since one that contradicts observed behaviour is
worse than none — someone would eventually act on it.

Worth noting the OpenMP arm passed both variants tested, which is weak evidence that the
current rendering may work in practice for this pattern.

What would settle it. The OpenMP 5.x spec text on implicit pointer attachment — specifically
whether mapping a pointer component while its parent is already present is required to attach.
If it is, the fix is small and well-defined: emit the parent-then-pointee sequence under OpenMP,
matching what ACC_SETUP_SFs already does for OpenACC —

$:GPU_ENTER_DATA(copyin=('[' + arg + ']'))          ! parent first
if (associated(${arg}$%sf)) then
    $:GPU_ENTER_DATA(copyin=('[' + arg + '%sf]'))   ! pointee second -> attaches
end if

— rather than map(always,tofrom:). If the spec leaves it unspecified, then MFC is relying on
unportable behaviour on both models and the fix is larger.

Priority read: worth fixing on correctness grounds, because substituting a data copy for
pointer attachment is fragile even where it happens to work. Not urgent, and should not be
described as a known-broken path.