From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <goldstein.w.n@gmail.com>
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com
 [IPv6:2607:f8b0:4864:20::331])
 by sourceware.org (Postfix) with ESMTPS id E72993858D28
 for <libc-alpha@sourceware.org>; Wed,  6 Jul 2022 20:30:42 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E72993858D28
Received: by mail-ot1-x331.google.com with SMTP id
 s13-20020a0568301e0d00b00616ad12fee7so12594273otr.10
 for <libc-alpha@sourceware.org>; Wed, 06 Jul 2022 13:30:42 -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=7fjg8v9CGM+TzAWM6Zd3iqEam6TKg4KnNB7BeAcHfwI=;
 b=afObPVr7gE1UfnN6rTLG1VtVfPIra3zn/QNyL9ZgNUNOnoyJ6nMq6ODsgW9UEDz70k
 BEYREI2oc0wfqFYn8JLUh2x6YFRncemcAumXxbK+Xfutvy/xC4yyO3itl2kd5Ft6U/M2
 brn+qTQ7V20bk1FaMmIn3vdlJgHIfdmJ9ibGq6l6M2srjrPdyUf0pdLHqn5QR+KOFmpo
 EMH6KyRgFXL2TN8SuvB0RixjMi3iTLUS5uvZxcduDyXfQZJxTzD+YX0dfNxXmAX4iiST
 g9PXLa8zyMNVLI4MIZUWPEneWvppGWuaC7k9047TfdwP28oWmDonoS/GTtKNBAPMRyVo
 w4gQ==
X-Gm-Message-State: AJIora8CREedhogc1g8vevgB9yiXigXJhLKHzYqCUbiXEGSDmGu531+9
 P927NNq1p0OXZmvM9zOJ/WARA+62tJNLRUaIJX1JL2Pr
X-Google-Smtp-Source: AGRyM1tFU2OI/bDP7cQi0QSJN+Vh299nEZlicpIeMGbJFpc5KVNt0QyM0UziNqPF16mmlFPuHZj64F4dxU44hHXy5Bc=
X-Received: by 2002:a05:6830:4420:b0:616:e569:8ae9 with SMTP id
 q32-20020a056830442000b00616e5698ae9mr17502379otv.265.1657139442221; Wed, 06
 Jul 2022 13:30:42 -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>
In-Reply-To: <AM5PR0801MB1668526F8010E1A4C3F8083783809@AM5PR0801MB1668.eurprd08.prod.outlook.com>
From: Noah Goldstein <goldstein.w.n@gmail.com>
Date: Wed, 6 Jul 2022 13:30:31 -0700
Message-ID: <CAFUsyfL5fsHOtOX0KN2g6xSJHcxNnUu-YSR0=5nutkNSvEapgg@mail.gmail.com>
Subject: Re: [PATCH 3/7] Remove atomic_bit_set/bit_test_set
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-3.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:30:45 -0000

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.

>
> Cheers,
> Wilco