From patchwork Thu Jan 21 00:11:08 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Sebor X-Patchwork-Id: 570973 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 04529140BA4 for ; Thu, 21 Jan 2016 11:11:27 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=qG+63hY7; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:content-type; q= dns; s=default; b=pFqTwOJbjIvv3sDMS+p9xlaBERCiTK2Dlcv7Itkrip3loY hWi+fhxHApWZXq+OTE435t4iFbYCx/H2WLIyWVBjeyf68rmA4zn4TZ2LdWKmPe2V cghGrMSaLWxPjvEDpGaReTTbnInY5fxp8NFGI465cUAD6GRIGRrdLpi9zlrKU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:content-type; s= default; bh=4LStrDFkBsf+d5nVj9aQ4eqYQ1w=; b=qG+63hY7de1KuJN3sEJD Bl6lRnn3CvuxiH+kTC/rSnXeYXoVSdSQwlg2ZlLcO7W62dUA9JW7bTpb0xfUU25D o/lVkI9LzEpBIkhd9vLFSo39Qa26No53JoV3Tasa09qRRCtZ4JMbMAjpBfcVpRFs wEbX28XTSvkFxbK9MeoLDvs= Received: (qmail 106906 invoked by alias); 21 Jan 2016 00:11:15 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 106886 invoked by uid 89); 21 Jan 2016 00:11:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=operated, uintptr_t, _Bool, _bool X-HELO: mail-qk0-f175.google.com Received: from mail-qk0-f175.google.com (HELO mail-qk0-f175.google.com) (209.85.220.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 21 Jan 2016 00:11:13 +0000 Received: by mail-qk0-f175.google.com with SMTP id o6so10058337qkc.2 for ; Wed, 20 Jan 2016 16:11:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=OLCWagQhSFmwnF4IndyuC7QYUtyoEvwoJzFDDg4ghio=; b=hPJIokENt1tyf/IpVGY4u/xHyKf/tt2xTzQFBWNY8MBxfldBXk1o8myMwivZboMx58 g5j5ARKILhS/sqafW6VFMu2pHEkkmRDuHn2hforkyb4JJa+tTyP+J8yzXt3whwxPn4R2 Io1aSCcKChdjEERx9hA4TuYDtc5DDDbYSY3Mf5pzONyVdP+1OPsdhNvyMUrlDbMn1hDs skMVE3TsPLxGeWAQ1UDHij5sFFZVsA6qPaDuSrra0nN31LCL2f8dDLIUGu4ETtWR6ZY2 zPTlpwDv5djmIBvX6oBepjfxjclwsW0U1CwF0lSYFaRvHHoLm14W7oJZ/+16TCtUeKdd 6tfg== X-Gm-Message-State: ALoCoQn8uPmZh9osSLaS5Is2ubV+zhQN49FUt6Zkkv49GLvPXzpooJ+/jYEzU6u/A3dz5Qi5mlOWSIMmdua+UIpaPGStkLMMzw== X-Received: by 10.55.72.146 with SMTP id v140mr48591231qka.63.1453335071644; Wed, 20 Jan 2016 16:11:11 -0800 (PST) Received: from [192.168.0.26] (71-212-229-169.hlrn.qwest.net. [71.212.229.169]) by smtp.gmail.com with ESMTPSA id a130sm7570019qhd.9.2016.01.20.16.11.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jan 2016 16:11:10 -0800 (PST) Message-ID: <56A0221C.5060506@gmail.com> Date: Wed, 20 Jan 2016 17:11:08 -0700 From: Martin Sebor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gcc Patch List Subject: [PATCH] #52291 - clarify sync_fetch_and_OP for pointers X-IsSubscribed: yes The bug points out that while the __sync_fetch_and_OP intrinsics are documented to have semantics equivalent to the "x OP= y" compound assignment expressions, when used with pointer operands they actually behave as if they operated on integers. I.e., they are not scaled by the size of the pointed-to type. The attached patch brings the documentation of both the __sync_ and the __atomic_ intrinsics into alignment with their actual effects. Martin PS See also c/64843 for some additional background. 2016-01-20 Martin Sebor PR c/52291 * extend.texi (__sync Builtins): Clarify the semantics aof __sync_fetch_and_OP built-ins on pointers. (__atomic Builtins): Same. Index: gcc/doc/extend.texi =================================================================== --- gcc/doc/extend.texi (revision 232636) +++ gcc/doc/extend.texi (working copy) @@ -9262,8 +9262,11 @@ work on multiple types. The definition given in the Intel documentation allows only for the use of the types @code{int}, @code{long}, @code{long long} or their unsigned -counterparts. GCC allows any integral scalar or pointer type that is -1, 2, 4 or 8 bytes in length. +counterparts. GCC allows any scalar type that is 1, 2, 4 or 8 bytes in +size other than the C type @code{_Bool} or the C++ type @code{bool}. +Operations on pointer operands are performed as if the operands were +of the @code{uintptr_t} type. That is, they are not scaled by the size +of the type to which the pointer points. These functions are implemented in terms of the @samp{__atomic} builtins (@pxref{__atomic Builtins}). They should not be used for new @@ -9309,7 +9312,11 @@ accessible variables should be protected @findex __sync_fetch_and_xor @findex __sync_fetch_and_nand These built-in functions perform the operation suggested by the name, and -returns the value that had previously been in memory. That is, +returns the value that had previously been in memory. That is, operations +on integer operands have the following semantics. Operations on pointer +operands are performed as if the operands were of the @code{uintptr_t} +type. That is, they are not scaled by the size of the type to which +the pointer points. @smallexample @{ tmp = *ptr; *ptr @var{op}= value; return tmp; @} @@ -9335,7 +9342,9 @@ as @code{*ptr = ~(tmp & value)} instead @findex __sync_xor_and_fetch @findex __sync_nand_and_fetch These built-in functions perform the operation suggested by the name, and -return the new value. That is, +return the new value. That is, operations on integer operands have +the following semantics. Operations on pointer operands are performed as +if the operands were of the @code{uintptr_t} type. That is, they are not +scaled by the size of the type to which the pointer points. @smallexample @{ *ptr @var{op}= value; return *ptr; @} @@ -9592,7 +9601,9 @@ pointer. @deftypefnx {Built-in Function} @var{type} __atomic_or_fetch (@var{type} *ptr, @var{type} val, int memorder) @deftypefnx {Built-in Function} @var{type} __atomic_nand_fetch (@var{type} *ptr, @var{type} val, int memorder) These built-in functions perform the operation suggested by the name, and -return the result of the operation. That is, +return the result of the operation. Operations on pointer operands are +performed as if the operands were of the @code{uintptr_t} type. That is, +they are not scaled by the size of the type to which the pointer points. @smallexample @{ *ptr @var{op}= val; return *ptr; @} @@ -9610,7 +9621,10 @@ type. It must not be a Boolean type. A @deftypefnx {Built-in Function} @var{type} __atomic_fetch_or (@var{type} *ptr, @var{type} val, int memorder) @deftypefnx {Built-in Function} @var{type} __atomic_fetch_nand (@var{type} *ptr, @var{type} val, int memorder) These built-in functions perform the operation suggested by the name, and -return the value that had previously been in @code{*@var{ptr}}. That is, +return the value that had previously been in @code{*@var{ptr}}. Operations +on pointer operands are performed as if the operands were of +the @code{uintptr_t} type. That is, they are not scaled by the size of +the type to which the pointer points. @smallexample @{ tmp = *ptr; *ptr @var{op}= val; return tmp; @}