This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/50583] Many __sync_XXX builtin functions are incorrect
- From: "amacleod at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 30 Sep 2011 18:25:51 +0000
- Subject: [Bug target/50583] Many __sync_XXX builtin functions are incorrect
- Auto-submitted: auto-generated
- References: <bug-50583-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50583
Andrew Macleod <amacleod at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> 2011-09-30 18:25:51 UTC ---
Technically it is closer to
do {
tmp = *ptr;
tmp1 = tmp OP value;
} while (__sync_val_compare_and_swap (ptr, tmp, tmp1) != tmp);
return tmp;
except it uses the new value of tmp from the CAS rather than reloading it
again.
It loops performing OP on the new value of tmp until the CAS is successful.
Functionally it is identical, what is your case where it can't be used?
The only difference I see is that another very hostile process which constantly
changes *ptr may prevent forward progress from ever happening, resulting in an
infinite loop.
At the moment we aren't making any guarantees of forward progress, although I
think at some point we may want to add a flag to the compiler as it becomes
more of an issue. With a flag like that enabled, a CAS loop would not be a
valid implementation.