clang error with OpenMP atomic capture compare

[krzikalla]

I'd like to draw your attention on llvm/llvm-project#127466 (comment)

It looks like clang has still serious problems with the #pragma omp atomic capture compare construct used in include/alpaka/atomic/AtomicOmpBuiltIn.hpp.
I wonder if alpaka can provide a workaround.

[psychocoderHPC]

Thanks for pointing us to the issue.
Currently, I do not think that we can handle the issue in our code base. The issue was triggered by a user-defined operator and it looks really like a bug in clang.
If you know how to work around the issue please let us know. I played a little bit with your godbold example but have not found a workaround.

[psychocoderHPC]

@krzikalla Is the error triggered by a operator definition within alpaka or is the operator defined in your code base?
I figured out that the compile issue is always showing up if the binary operator used within the atomic is defined in the corresponding namespace too.

llvm/llvm-project#127466 (comment)

So if you do not define the operator <, >, ... within alpaka all should work as expected.

Defining the operator in a higher namespace e.g. the global namespace is producing issues too.

[q-p]

@krzikalla Is the error triggered by a operator definition within alpaka or is the operator defined in your code base? I figured out that the compile issue is always showing up if the binary operator used within the atomic is defined in the corresponding namespace too.

The operator is defined in a third party AD library, and we don't get to choose where it puts its operators.

[psychocoderHPC]

@q-p Thanks for the information. Currently, I do not see how we can work around the compiler bug.

I think we must wait until llvm is fixing the issue.