From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48976 invoked by alias); 13 Jan 2016 14:27:25 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 48958 invoked by uid 89); 13 Jan 2016 14:27:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=extend.texi, extendtexi, UD:extend.texi, Hx-languages-length:2679 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 13 Jan 2016 14:27:18 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 86D904F638; Wed, 13 Jan 2016 14:27:16 +0000 (UTC) Received: from localhost (ovpn-116-32.ams2.redhat.com [10.36.116.32]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0DERF2h002973; Wed, 13 Jan 2016 09:27:16 -0500 Date: Wed, 13 Jan 2016 14:27:00 -0000 From: Jonathan Wakely To: Sandra Loosemore Cc: Andrew Haley , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Clarify __atomic_compare_exchange_n docs Message-ID: <20160113142715.GJ15084@redhat.com> References: <20150929120038.GW12094@redhat.com> <560AAC7B.4030904@codesourcery.com> <560D18EB.5090900@redhat.com> <560D73F5.9090908@codesourcery.com> <20151001183518.GL12094@redhat.com> <20151001184007.GN12094@redhat.com> <20151003130026.GG12094@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20151003130026.GG12094@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-01/txt/msg00823.txt.bz2 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 Date: Sat Oct 3 13:59:47 2015 +0100 Clarify __atomic_compare_exchange effects * doc/extend.texi (__atomic Builtins): Clarify compare_exchange effects. 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