From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id B77523858D20 for ; Thu, 29 Dec 2022 12:09:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B77523858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52c.google.com with SMTP id c34so19857787edf.0 for ; Thu, 29 Dec 2022 04:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zWvJgnSd9jbaJimJ5ZhNrd7X5phy4VNwjdI8RlAAIx8=; b=BXyWDXDT61RPOJmXmNxFkC3jHZqK6YwxbzbfzpwQnFRS4LmhUqlWkQammUyP84/hFq j5EcOpvGv+3OBSjQlIvKURdgjFm68GoONeYliEK355T8TiHYbZX20d+A5N4V85A6nOtW 1bGUXVFFmVEpgmzJPUmuQY3GZVt9IJx3w6WSwhTY3wO7UKOuGfpFfIJkz10hUv43iUAz vyvGAhxZelLOQhm30QaQtlmTQRDi9XT5oxxfb/BAQJoybc/pqU1k8FRBqv/V4My4Yg87 fGknMvnBDRCyQcLt2uhJvq3gThdVcX4E/vzgXsSmpkE+3Lj/nW04S/mm9oFwh6vHM4CO YoxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zWvJgnSd9jbaJimJ5ZhNrd7X5phy4VNwjdI8RlAAIx8=; b=Gyl1C4ZW8Lx4ldjuBXQsYeF03utN6Ihksvv5oQ+4ue3ZseGaepMP+YIfG/6+2/yKiV TujelLW+aFqGNU78iJ9SMaaL1bYbnIKUhfc6Knza4tAg1J0g7KNiP9KO04/7a9Wa76G1 w3DAr2eY5PeYRPYm9kZGCVGM9pxNnkIJ7sKf/xah0WxWdowjS4f6Ck+hO/NFJwDMrqWP /ddIbvnf/SklpxWGrpSm11regl+ZlyEsoOckrNbD3oGKZv29q1hQPkADGX7ny5s0HE5J 1INxEHrzITCyDCNXWO0D92fEUlY+UtDYpHjMjfTZKy9i85kNUXNL1gkW719wELHEey2X d+FQ== X-Gm-Message-State: AFqh2krkybXHl/sSzbviAig19mZy6Hq2z53CX2TvN5uGv4nnINrMcgf0 3tO51lX5uYskq8EjvRVbz3e4nLNFVV8uYFr/byE= X-Google-Smtp-Source: AMrXdXsdPc0E2e92p+ilWrAp3/3mLIJEBHC+hipNXHJik7Svj87alyZuYruQ7y5S400ujOCifvD47u+MfqVObFPLL1o= X-Received: by 2002:a05:6402:2993:b0:46c:af80:636c with SMTP id eq19-20020a056402299300b0046caf80636cmr3084730edb.129.1672315780427; Thu, 29 Dec 2022 04:09:40 -0800 (PST) MIME-Version: 1.0 References: <6640F26B-F267-40E0-9223-2F0F45462176@sandoe.co.uk> In-Reply-To: <6640F26B-F267-40E0-9223-2F0F45462176@sandoe.co.uk> From: Jonathan Wakely Date: Thu, 29 Dec 2022 12:09:29 +0000 Message-ID: Subject: Re: [RFA] choosing __platform_wait_t on targets without lock-free 64 atomics To: Iain Sandoe Cc: "libstdc++" , Thomas Rodgers Content-Type: multipart/alternative; boundary="0000000000000b75bb05f0f65cbc" X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000000b75bb05f0f65cbc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 29 Dec 2022, 11:29 Iain Sandoe, wrote: > Hi, > > The recent addition of the tz handling has pulled in a dependency on > > > This currently specifies __platform_wait_t as a 64bit quatity on platforms > without _GLIBCXX_HAVE_LINUX_FUTEX. > > PowerPC does not have a 64b atomic without library support - so that this > causes a bootstrap > fail on powerpc-darwin (and I guess any other 32b powerpc non-futex > target). > > Rather than contrive to build and add libatomic (which is not at present > available at the point > that libstdc++ is built), I wonder if there is any specific reason that > __platform_wait_t needs > to be 64 bits on these platforms? (Especially since the futex case uses an > int.) > I think we do want the generic case's _M_wait atomic variable to be lock free, otherwise we use two locks for every operation, the one in libatomic and the waiter mutex. That's more important than it being any specific width. > Advice on the right way to fix this welcome =E2=80=94 as a work-around to= allow > bootstrap to complete > I applied the patch below - but that seems unlikely to be the right thing > generically . Rather than __lp64__ I think we should check the ATOMIC_LONG_LOCK_FREE macro and use long if it's lock free and int otherwise. But Tom needs to confirm that. That would be approximately the same as your patch in practice. > thanks > Iain > > ---- > > > diff --git a/libstdc++-v3/include/bits/atomic_wait.h > b/libstdc++-v3/include/bits/atomic_wait.h > index bd1ed56..2f67180 100644 > --- a/libstdc++-v3/include/bits/atomic_wait.h > +++ b/libstdc++-v3/include/bits/atomic_wait.h > @@ -64,7 +64,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > // and __platform_notify() if there is a more efficient primitive > supported > // by the platform (e.g. __ulock_wait()/__ulock_wake()) which is better > than > // a mutex/condvar based wait. > +#if __LP64__ > using __platform_wait_t =3D uint64_t; > +#else > + using __platform_wait_t =3D uint32_t; > +#endif > inline constexpr size_t __platform_wait_alignment > =3D __alignof__(__platform_wait_t); > > --0000000000000b75bb05f0f65cbc--