diff mbox

Clarify __atomic_compare_exchange_n docs

Message ID 20160113142715.GJ15084@redhat.com
State New
Headers show

Commit Message

Jonathan Wakely Jan. 13, 2016, 2:27 p.m. UTC 
On 03/10/15 14:00 +0100, Jonathan Wakely wrote:
>Here's the latest version of the patch, including the typo fix.

Is this patch OK for trunk?

The original thread faded out, it's split across two months in the
archives:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02190.html
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00307.html

While we might be able to make further improvements I think this is
better than what we have now (and I'm hoping not to spend much more
on it ;-)


commit 96468d6b7e782501459bad306b31d45bc0ba5155
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Sat Oct 3 13:59:47 2015 +0100

    Clarify __atomic_compare_exchange effects
    
    	* doc/extend.texi (__atomic Builtins): Clarify compare_exchange
    	effects.

Comments

Sandra Loosemore Jan. 13, 2016, 5:16 p.m. UTC | #1 
On 01/13/2016 07:27 AM, Jonathan Wakely wrote:
> On 03/10/15 14:00 +0100, Jonathan Wakely wrote:
>> Here's the latest version of the patch, including the typo fix.
>
> Is this patch OK for trunk?
>
> The original thread faded out, it's split across two months in the
> archives:
>
> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02190.html
> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00307.html
>
> While we might be able to make further improvements I think this is
> better than what we have now (and I'm hoping not to spend much more
> on it ;-)

I apologize for losing track of this patch during the previous 
discussion.  The version you have now is OK to commit.

-Sandra
Jonathan Wakely Jan. 13, 2016, 7:26 p.m. UTC | #2 
On 13/01/16 10:16 -0700, Sandra Loosemore wrote:
>On 01/13/2016 07:27 AM, Jonathan Wakely wrote:
>>On 03/10/15 14:00 +0100, Jonathan Wakely wrote:
>>>Here's the latest version of the patch, including the typo fix.
>>
>>Is this patch OK for trunk?
>>
>>The original thread faded out, it's split across two months in the
>>archives:
>>
>>https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02190.html
>>https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00307.html
>>
>>While we might be able to make further improvements I think this is
>>better than what we have now (and I'm hoping not to spend much more
>>on it ;-)
>
>I apologize for losing track of this patch during the previous 
>discussion.  The version you have now is OK to commit.

No problem, I'd forgotten about it myself until I was clearing out
some local Git branches. It's committed now.
diff mbox

Patch

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 8406945..599ad87 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -9353,17 +9353,18 @@  This compares the contents of @code{*@var{ptr}} with the contents of
 @code{*@var{expected}}. If equal, the operation is a @emph{read-modify-write}
 operation that writes @var{desired} into @code{*@var{ptr}}.  If they are not
 equal, the operation is a @emph{read} and the current contents of
-@code{*@var{ptr}} is written into @code{*@var{expected}}.  @var{weak} is true
-for weak compare_exchange, and false for the strong variation.  Many targets 
+@code{*@var{ptr}} are written into @code{*@var{expected}}.  @var{weak} is true
+for weak compare_exchange, which may fail spuriously, and false for
+the strong variation, which never fails spuriously.  Many targets 
 only offer the strong variation and ignore the parameter.  When in doubt, use
 the strong variation.
 
-True is returned if @var{desired} is written into
-@code{*@var{ptr}} and the operation is considered to conform to the
+If @var{desired} is written into @code{*@var{ptr}} then true is returned
+and memory is affected according to the
 memory order specified by @var{success_memorder}.  There are no
 restrictions on what memory order can be used here.
 
-False is returned otherwise, and the operation is considered to conform
+Otherwise, false is returned and memory is affected according
 to @var{failure_memorder}. This memory order cannot be
 @code{__ATOMIC_RELEASE} nor @code{__ATOMIC_ACQ_REL}.  It also cannot be a
 stronger order than that specified by @var{success_memorder}.
@@ -9470,7 +9471,7 @@  alignment.  A value of 0 indicates typical alignment should be used.  The
 compiler may also ignore this parameter.
 
 @smallexample
-if (_atomic_always_lock_free (sizeof (long long), 0))
+if (__atomic_always_lock_free (sizeof (long long), 0))
 @end smallexample
 
 @end deftypefn