[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

amacleod at redhat dot com gcc-bugzilla@gcc.gnu.org
Thu Apr 16 12:25:00 GMT 2015


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.



More information about the Gcc-bugs mailing list