On Mon, 2018-02-26 at 22:45 +0000, Ruslan Nikolaev via gcc wrote: > Thanks, everyone, for the output, it is very useful. I am just proposing to > consider the change unless there are clear roadblocks. (Either design choice > is probably OK with respect to the standard formally speaking, but there are > some clear advantages also.) I wrote a summary of pros & cons (which, of > course, is slightly biased towards the change :) ) > I also opened Bug 84563 with the rationale.
This bug summarizes your perspective on the matter. I'd call that not just slightly biased :) I do not see a reason to change GCC's position regarding this topic. We should update the docs though to clarify the intent and guarantees GCC's implementation gives, I suppose. The reasons have been discussed elsewhere in this thread already, so I'm not going to repeat them here. > 1. Ability to use guaranteed lock-free double-width atomics (when mcx16 is > specified for x86-64, and always for arm64) in more or less portable manner > across different supported architectures (without resorting to non-standard > extensions or writing separate assembly code for each architecture). That's a valid goal, but it does not imply that we should mess with how atomics are implemented by default, nor should we mess with the default use cases. This goal wants something special, and that is exposing the fact that *only* a CAS is available to synchronize atomically on a particular type. That is an extension of the existing atomics design. There are different ways to expose such an extension, with one being to simply provide a __atomic_special_cas builtin or something like that. It would have the same synchronization semantics as the normal CAS, but concurrent access between the special CAS and the normal atomics would be considered a data race (so making sure that there's no guaranteed atomicity between them). It could have a fallback to libatomic for ease of use, and it could be defined for smaller types too. This would be portable, and would allow us to separate the different use cases. > 7. Ability to finally deprecate old __sync builtins, and use new and more > advanced __atomic everywhere. The topic we're currently discussing does not significantly affect when we can remove __sync builtins, IMO.
