This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-09 15:45:06 UTC ---
(In reply to comment #1)
> The docs of __sync_* say
> 
> This builtin is not a full barrier, but rather an @dfn{acquire barrier}.
> This means that references after the builtin cannot move to (or be
> speculated to) before the builtin, but previous memory stores may not
> be globally visible yet, and previous memory loads may not yet be
> satisfied.
> 
> But it is not exactly clear to which builtins this applies.  Thus, is
> the intended behavior actually target depedent?

It refers to __sync_lock_test_and_set only (it says "this builtin" and follows
that one)

And "This builtin is not a full barrier, but rather a release barrier." refers
to __sync_lock_release.

All the others are full barriers.  It says above them "In most cases, these
builtins are considered a full barrier." and only __sync_lock_test_and_set and
__sync_lock_release specify different barrier semantics.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]