Andrey Alekseenko

Nice catch, thanks! It is indeed [a possible logging output](https://github.com/notpeter/dante/blob/master/dante/sockd/sockd_negotiate.c#L674). Fixed and added a test for this particular case. Also rebased the whole branch to avoid unrelated failed tests.

> They are stack-specific and hence may not be available in all cases That's a valid point. But I don't think that we have any cross-platform solution to get a...

Per my experience, Clang optimizes this into `global_atomic_add_f32` when the result is not used, because that's the limitation of floating-point atomics on GFX908. If it can not prove that the...

> Thank you, @al42and, for the link. I couldn't find your workaround on the official GROMACS repo. Could you point me to the right branch? When atomicAddNoRet was used with...

> IMO the real bug here is that sqrt() is not IEEE754 compliant - the spec does not guarantee that the native functions have to be faster (they may), but...

> I don't think putting in quotes is a big issue... Not a big issue, but can cause a bit more head-scratching than necessary when one starts with a single...

FYI, Related proposal in DPC++: https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/IntelGPU/IntelGPUDeviceInfo.md#pci-address.

> How do you suggest to work around this? We need some sort of compiler support to be able to guarantee atomic load semantics. Those have not been validated, just...

Also, `atomicAdd(ptr, 0)`/`atomicOr(ptr, 0)` should do the trick. That said, for GROMACS that is not a pressing concern. I mostly opened this issue to record and document the problem, not...

Issue still present in IntelLLVM 962417da7c70e9c94ff767b05f266fa1add42f83, compute-runtime 22.04.22286.