On Mon Jun 19 13:22:09 2023 +0000, Jinoh Kang wrote:
I don't think `volatile` on an unrelated variable can suppress any undesired optimization, or act as a barrier at all[^vol], unlike MSVC. MSVC doesn't necessarily treat `volatile` accesses as an acquire/release barrier either if `/volatile:iso` is specified[^msvc]. [^vol]: [Why the "volatile" type class should not be used](https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.h...) [^msvc]: [volatile (C++) | Microsoft Learn](https://learn.microsoft.com/en-us/cpp/cpp/volatile-cpp?view=msvc-170)
It is not a barrier with normal load/store operations, but I believe it is with other volatile accesses. Everything that is written between `SHARED_WRITE_BEGIN` / `SHARED_WRITE_END` is volatile, so as I understand it, ordering should be guaranteed.
Fwiw I wouldn't mind using __atomic builtins everywhere, I'm not sure to see how it is better to have to argue about volatile semantics every time, to keep compatibility with some unknown compiler that would not support them. GCC >= 4.7 has them, which imho is old enough, and I don't think we will ever build wineserver with MSVC, but if we do it would not be too difficult to adjust then.