From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32948 invoked by alias); 3 Mar 2020 17:11:06 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 32931 invoked by uid 89); 3 Mar 2020 17:11:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.1 spammy=compound, laid X-HELO: cerberus.halldom.com Received: from cerberus.halldom.com (HELO cerberus.halldom.com) (79.135.97.241) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Mar 2020 17:11:03 +0000 Received: from ceres.halldom.com ([79.135.97.244]:52685) by cerberus.halldom.com with esmtpsa (TLSv1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.92.3) (envelope-from ) id 1j9B4P-0000kI-7j for gcc-help@gcc.gnu.org; Tue, 03 Mar 2020 17:11:01 +0000 Subject: Are atomic_fetch_xxx() functions broken for atomic-pointer types ? References: <174d5d4b-b983-b4b3-9313-d71992f3c6c2@gmch.uk> From: Chris Hall To: gcc-help X-Forwarded-Message-Id: <174d5d4b-b983-b4b3-9313-d71992f3c6c2@gmch.uk> Message-ID: Date: Tue, 03 Mar 2020 17:11:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <174d5d4b-b983-b4b3-9313-d71992f3c6c2@gmch.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2020-03/txt/msg00013.txt Another issue ? ----- In Section 7.17.7.5 "The atomic_fetch and modify generic functions", the C11/C18 Standards say: 1 The following operations perform arithmetic and bitwise computations. All of these operations are applicable to an object of any atomic integer type. ... 5 NOTE The operation of the atomic_fetch and modify generic functions are nearly equivalent to the operation of the corresponding op= compound assignment operators. The only differences are that the compound assignment operators are not guaranteed to operate atomically, and the value yielded by a compound assignment operator is the updated value of the object, whereas the value returned by the atomic_fetch and modify generic functions is the previous value of the atomic object. So given: _Atomic(uint64_t*) foo ; uint64_t* bar ; bar = atomic_fetch_add(&foo, 1) ; why do gcc 9.2/glibc 2.30 add 1 and not 8 to the address ? I note that maps atomic_fetch_add() to the built-in __atomic_fetch_add(), which is indeed defined to work this way. I grant that Section 7.17.7.5 is not a miracle of clarity (even by the standards of the Standards). You could argue that atomic_fetch_xxx() are simply not defined for atomic pointer types. But if so, *quietly* accepting an undefined argument and then doing something odd with it, strikes me as perverse. FWIW: since the bitwise 'op=' are not defined for pointer types, it is also a "surprise" that atomic_fetch_and() etc. accept pointer types. It seems to me that gcc/glibc are broken, as are the Standards. How to address that at this late stage looks tricky to me :-( Perhaps the Standards could have a big dollop of Implementation Defined retro-fitted; laid on thickly enough that might cover over the existing mess ? ----- I note that is not mentioned in the GNU C manual for v9.2.0 and also not mentioned in GNU C Library Reference Manual for v2.31... So I'm guessing that 9 or so years after the C11 standard, this remains such a mess that nobody can face trying to fix it ?