https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #34 from Andrew Macleod <amacleod at redhat dot com> --- > However, I guess some people relying on data races in their programs could > (mis?)understand the __sync_lock_release semantics to mean that it is a > means to get the equivalent of a C11 release *fence* -- which it is not > because the fence would apply to the (erroneously non-atomic) store after > the barrier, which could one lead to believe that if one observes the store > after the barrier, the fence must also be in effect. Thoughts? before we get too carried away, maybe we should return to what we *think* __sync are suppose to do. It represents a specific definition by intel.. From the original documentation for __sync "back in the day", and all legacy uses of sync should expect this behaviour: "The following builtins are intended to be compatible with those described in the "Intel Itanium Processor-specific Application Binary Interface", section 7.4. As such, they depart from the normal GCC practice of using the ``__builtin_'' prefix, and further that they are overloaded such that they work on multiple types." The definition of "barrier" from that documentation is : acquire barrier : Disallows the movement of memory references to visible data from before the intrinsic (in program order) to after the intrinsic (this behavior is desirable at lock-release operations, hence the name). release barrier: Disallows the movement of memory references to visible data from after the intrinsic (in program order) to before the intrinsic (this behavior is desirable at lock-acquire operations, hence the name). full barrier: disallows the movement of memory references to visible data past the intrinsic (in either direction), and is thus both an acquire and a release barrier. A barrier only restricts the movement of memory references to visible data across the intrinsic operation: between synchronization operations (or in their absence), memory references to visible data may be freely reordered subject to the usual data-dependence constraints. Caution: Conditional execution of a synchronization intrinsic (such as within an if or a while statement) does not prevent the movement of memory references to visible data past the overall if or while construct.
