From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hjl.tools@gmail.com>
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com
 [IPv6:2607:f8b0:4864:20::102c])
 by sourceware.org (Postfix) with ESMTPS id 7221D3857814
 for <libc-alpha@sourceware.org>; Wed,  6 Jul 2022 20:56:49 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7221D3857814
Received: by mail-pj1-x102c.google.com with SMTP id
 z12-20020a17090a7b8c00b001ef84000b8bso11257168pjc.1
 for <libc-alpha@sourceware.org>; Wed, 06 Jul 2022 13:56:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=tBmu904/MVRTA9lVDYMt0EZ+4Dn17XawTqH5afDgJds=;
 b=ZTgKuaQPwVN4alfS9RwNNgb8QvIRR1m0yn267SGLjOIWYd1xOJJcKipuJUx3gvydGG
 jLRmMvChWpP19DRyOdoJHEs6RG6MpclL3WccvONjuXByQSFRvmkIoienBurc9rv8RAMS
 nTsJekwUSlSjQWDzosTeWgGctJKiV67G4H21oGwXRoCNd4yeKZ+raxBCMiM87WkqZCWC
 HweG1MSiCru7P/PrDqrhlOr4WnQBtCxbmIifOPwj7H+GPc2yGbLHhdO2216jXUZupQgv
 s2elyd5qwMRdb4ZDy0GSj3u+oJL5MvHMCYTWpaBY/CtVI4mP6+u7jPUjPpbD1DDddY2r
 HsQA==
X-Gm-Message-State: AJIora9asqaVL2Ogl91Kzup7Om+TZinxSssDu3fgeZV0Vq99UMezyk/T
 kxVSy922lw21O3Re7cCq4iNCEk2pMmSZA+PD3cU=
X-Google-Smtp-Source: AGRyM1s/s1/pgZ9mkh2RUcmMd8RPxqKwerx6uPxOK4SGkRcheLnnXO5bKfd4oy04wFT78YkEccVAn15S19OtlhwtbIE=
X-Received: by 2002:a17:902:a502:b0:15e:c251:b769 with SMTP id
 s2-20020a170902a50200b0015ec251b769mr48971908plq.115.1657141008365; Wed, 06
 Jul 2022 13:56:48 -0700 (PDT)
MIME-Version: 1.0
References: <AM5PR0801MB1668D792891F7663B534D31883809@AM5PR0801MB1668.eurprd08.prod.outlook.com>
 <CAFUsyfLt0FwVtf3=7f6W_m6jxyrVH1fxcwMdCUvUp5GqGdSShg@mail.gmail.com>
 <CAFUsyfLT_-zAHVmQzwfjAztY9XbYoUeKigM53ZoN5P7-vQ__vw@mail.gmail.com>
 <AM5PR0801MB166890BEB51B13EF8EB84A0983809@AM5PR0801MB1668.eurprd08.prod.outlook.com>
 <CAFUsyf+y7qrFXk-qz6iZw5wkJ40aYh-K_5_RZYy8n993MnkJqA@mail.gmail.com>
 <AM5PR0801MB1668B2BB6C6560CCA3BA5E3083809@AM5PR0801MB1668.eurprd08.prod.outlook.com>
 <CAFUsyf+H5A1NqTBxwvvfVd7TzXJ8-J8HtUmUg8P9KVwEQYk9SQ@mail.gmail.com>
 <CAFUsyfLKkexj15C8q1d+LX9baUncwupg37tD=48uVmxnh598zA@mail.gmail.com>
 <AM5PR0801MB1668526F8010E1A4C3F8083783809@AM5PR0801MB1668.eurprd08.prod.outlook.com>
 <CAFUsyfL5fsHOtOX0KN2g6xSJHcxNnUu-YSR0=5nutkNSvEapgg@mail.gmail.com>
In-Reply-To: <CAFUsyfL5fsHOtOX0KN2g6xSJHcxNnUu-YSR0=5nutkNSvEapgg@mail.gmail.com>
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Wed, 6 Jul 2022 13:56:12 -0700
Message-ID: <CAMe9rOpP+oiXtM5MEPpp=r3c33TfadrQtJia02vh8yQ0cAS6mw@mail.gmail.com>
Subject: Re: [PATCH 3/7] Remove atomic_bit_set/bit_test_set
To: Noah Goldstein <goldstein.w.n@gmail.com>
Cc: Wilco Dijkstra <Wilco.Dijkstra@arm.com>,
 GNU C Library <libc-alpha@sourceware.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-3018.5 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
 SPF_HELO_NONE, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: libc-alpha@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jul 2022 20:56:51 -0000

On Wed, Jul 6, 2022 at 1:31 PM Noah Goldstein via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> On Wed, Jul 6, 2022 at 1:14 PM Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
> >
> > Hi Noah,
> >
> > The goal here is to move to the standard atomics, not to invent our own set for
> > convenience or just for fun to be different etc. There were 2 uses of atomic_bit_set
> > in all of GLIBC, and I cannot believe that atomic_fetch_or (&x, 1 << bit) could cause
> > any confusion given that it is very similar to x |= 1 << bit. We don't wrap such
> > expressions in macros like bitset (x, bit) either - it just doesn't make sense.
> >
> > As I mentioned, I'll use EXITING_BITMASK rather than 1 << EXITING_BIT.
>
> Alright.

Before GCC 12,

(__atomic_fetch_or (&x, MASK, __ATOMIC_ACQUIRE) & MASK) != 0;

will be optimized to "lock btsl" only if x is unsigned.  But cancelhandling in

if (atomic_bit_test_set (&pd->cancelhandling, TERMINATED_BIT) == 0)

is signed which leads to the much worse code when GCC 11 or older are
used.

-- 
H.J.