From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98562 invoked by alias); 6 Mar 2020 17:46:14 -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 98553 invoked by uid 89); 6 Mar 2020 17:46:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:CAFyWVa, HX-Languages-Length:1630 X-HELO: mail-wr1-f45.google.com Received: from mail-wr1-f45.google.com (HELO mail-wr1-f45.google.com) (209.85.221.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Mar 2020 17:46:12 +0000 Received: by mail-wr1-f45.google.com with SMTP id n15so3339441wrw.13 for ; Fri, 06 Mar 2020 09:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bmaPLDBog1+uxJv7eMv/fUjfr2mHVc3V9TAFPl1ZopQ=; b=bERh1p9XhtL+US7+U5SlVaY2pSydHze2gEJf9o4oOEXrPpb1F511R6k1Q+nnQFziqs HEYMmFW+s/APzmGd8/j164eHz7rQMae3/Rt8g/Gw2VMRQbyvd/ppWeIm6vCXJH3YCfcE PDJhKntti4mwoBVaSLcapRnm5qx67GT2I9FBs55AOOGqtddkh2CsHRHmF7hZ6x7A90QI LlcI+dO6KCgEfk4FblZz+53xN6jpiNYRPRi2a9TpkXKfDBvWBM/idOQIiZE/JzvLR+Ws 2WFXWmzoYDTh5w5nbgKq2gBWc5ldU5ZiuV5PGdXkDzCvpHEtVu2DhHFZLazkl0fFdtWu p/KA== MIME-Version: 1.0 References: <72f6344e-d8b2-bab4-b047-63e298063492@gmch.uk> <76f5d98b-affc-111b-5493-2557f8facaf1@gmch.uk> <02d60fa2-0671-31c3-3d4a-1749eb0a6c7b@gmch.uk> In-Reply-To: <02d60fa2-0671-31c3-3d4a-1749eb0a6c7b@gmch.uk> From: Jonathan Wakely Date: Fri, 06 Mar 2020 17:46:00 -0000 Message-ID: Subject: Re: Should atomic_xxx() functions reject not-_Atomic() arguments ? To: Chris Hall Cc: gcc-help Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-03/txt/msg00040.txt On Fri, 6 Mar 2020 at 16:17, Chris Hall wrote: > > On 28/02/2020 15:27, Chris Hall wrote: > > On 28/02/2020 01:01, Jim Wilson wrote: > >> On Thu, Feb 27, 2020 at 7:20 AM Chris Hall wrote: > >>> Now, the Standard also tells us that _Atomic(uint64_t) and uint64_t may > >>> have different sizes, representations and alignment. So I guess: > >>> bar = atomic_fetch_add(&bar, 1) ; > >>> should be an error ? > > >> __atomic_fetch_add accepts any integer or pointer type. So the fact > >> that _Atomic(uint64_t) and uint64_t may be different types is not a > >> problem, as long as they are still integer types. This works like an > >> overloaded function in C++. > >> > >> https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins > > > Sure. But the Standard atomic_fetch_add() takes an _Atomic(xxx)* (as > > the first parameter), and for the reasons given, I understand that > > uint64_t* is not compatible with _Atomic(uint64_t)*. I don't think GCC is treating them as though they are compatible. It just accepts a broader range of types than only _Atomic ones, and does the right thing for them all (apart from pointers where the arithmetic is wrong). > FWIW: clang gets this right, and where the Standard says a parameter > must be an _Atomic(foo_t)* [for a standard atomic_xxx()], clang rejects > foo_t* arguments. It's not clear to me that C actually requires it to be rejected, or if it's just undefined (in which case GCC's decision to accept it and do the obvious thing is OK).