[Flang][OpenMP] Incorrect execution result when using double precision complex in a statement within ATOMIC WRITE construct

[ohno-fj]

Version of flang : 22.0.0(ea3dbb8b0061a7e44cba92b6e4e4486c4a416d65)/AArch64

In the attached program (sngtatm029_21.f90), when using double precision complex in a statement within ATOMIC WRITE construct, the execution result is incorrect.
The same issue also occurs with quadruple precision complex.

In the following cases, the execution result is correct.

• Do not specify the compilation option (-fopenmp), or
• Remove ATOMIC WRITE construct, or
• Change double precision or quadruple precision to single precision, or
• Change complex to real or integer

The following are the test program, Flang, Gfortran and ifx compilation/execution results.

sngtatm029_21.f90:

program main
  complex(8)::c81
  complex(8)::c82
  c81=0
  c82=0
  write(6,*) "1 : c81 = ", c81
!$omp parallel
!$omp atomic write
  c81=c82+(1.0_8,1.0_8)
!$omp end parallel
  write(6,*) "2 : c81 = ", c81
end program main

$ export OMP_NUM_THREADS=2; flang -fopenmp sngtatm029_21.f90; ./a.out
 1 : c81 =  (0.,0.)
 2 : c81 =  (1.,0.)
$

$ flang sngtatm029_21.f90; ./a.out
 1 : c81 =  (0.,0.)
 2 : c81 =  (1.,1.)
$

$ export OMP_NUM_THREADS=2; gfortran -fopenmp sngtatm029_21.f90; ./a.out
 1 : c81 =                (0.0000000000000000,0.0000000000000000)
 2 : c81 =                (1.0000000000000000,1.0000000000000000)
$

$ export OMP_NUM_THREADS=2; ifx -qopenmp sngtatm029_21.f90; ./a.out
 1 : c81 =  (0.000000000000000E+000,0.000000000000000E+000)
 2 : c81 =  (1.00000000000000,1.00000000000000)
$

[KrxGu]

Hi, I’d like to investigate and send a fix here.

Repro observed with flang -fopenmp on AArch64: complex(8) inside !$omp atomic write stores only the real part; imaginary stays 0. Single-precision complex(4) is fine.

Hypothesis:
In the OpenMP IRBuilder non-scalar atomic path we pass the pointer-size to __atomic_store/__atomic_load instead of the object’s store size. For complex(8) that yields 8B on 64-bit targets instead of 16B.

Plan:

• Fix size computation in llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  • createAtomicWrite (and createAtomicRead if applicable): use DataLayout.getTypeStoreSize(XElemTy) rather than the pointer type.
• Add Flang lowering tests to verify 16-byte atomics for complex(8):
  • flang/test/Lower/OpenMP/atomic-write-complex.f90 → check @__atomic_store(i64 16, ...)
  • flang/test/Lower/OpenMP/atomic-read-complex.f90 → check @__atomic_load(i64 16, ...)
• Validate on AArch64 and x86_64 and include the reproducer from the report.

If someone is already on it, let me know; otherwise I’ll proceed and open a PR referencing this issue.