This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity
- From: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 09 Jan 2012 15:45:06 +0000
- Subject: [Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity
- Auto-submitted: auto-generated
- References: <bug-51766-4@http.gcc.gnu.org/bugzilla/>
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.