From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) by sourceware.org (Postfix) with ESMTPS id 637A23858C66 for ; Mon, 15 Jan 2024 03:46:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 637A23858C66 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 637A23858C66 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::112a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705290417; cv=none; b=ii7fAHc7tJ8V3CiiUwl5eOvxcUahSoZ82Oz+kmluBL981bqt/4CbJbaGBmLH8wFEGp0ntwQdq06HOi3L1p2TLcFCDSTxREoRE93eddaIM0+EGUEQZ8DZ6o/Wt7lwQBMxINpvzSZZJM4zNN+s6B/bj7JbK7PzDRaI7Z6syupBbmA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705290417; c=relaxed/simple; bh=h9hvrgfL3QDN4Cp8R/y5kZ78wuKvmuyj4joSiuqMMkU=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=LmC7I4VY7tVQDvpdtWsC07ZjVX50KR4a9+++7XWnqh9lPTWVu+KUqmzhYGLYvaUnI6aQo3W2dwe4Dc04gPwbNhcalz6uRUwp09fRkVk2WN4bGWDc9E47TPsnYVPTZP7v1ljV5z3eoVpj/OTBfXxqVzh6J8Wf41FiermwHJEbQgo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-5f75aee31d2so72737367b3.2 for ; Sun, 14 Jan 2024 19:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705290413; x=1705895213; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gruDcUD4ebzpRHH3v/zgENmsqXCrjSMBO/TLykjXmxU=; b=CRXHOpw8NViip4q9Y0kONRgEIcAL59tSHk8xvf0gXMHx9ZksPCbynl2gajuESniFIl BSAgc2vxCx9aB+7UMKF8LBIToKv1ZXaGanx6jVBP0ezpSso05hVoRxTCNX5ynMiXIoL5 decPsTWmbjlW6x9dd1P9UxM8PK9LwSKyrzkyuk6CKZvwGfsff8NMgIFQwX2HNGv/hBLX 1v50oQ0iaVvGSvIrwtquWIACxhAjq5AnHo4Q3LsHa3VRxJafIM7atg5t7eXTANywhGna KbELvnxQcpx9kHwQlqEY0XEsxiwgyehtEofz3xP5IvTo19CzaSO/Srk/WMfyGg4rPr9B IyXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705290413; x=1705895213; 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=gruDcUD4ebzpRHH3v/zgENmsqXCrjSMBO/TLykjXmxU=; b=eP26cp2ugdJhKZsO9Lo18lhZ5QrkyS+Bc1YqUWnQvrCNxyiRfm4d3OiHd7Q6nohC+A 5rl1T/8mS+trKlzhAv72tZMQ75edsYfZ0GdDL41ul1TI//uS0vBXUa3k1/2XDMv26Nbb uhYc2MnN5ZMYNZ3hLMFFQdrUoW9Eft6bktfxPlDrFlmMd5QgY8Znl4eEihAsY9WJFl08 2VdQ4XlTbY4h98K5EFboVudaRbkoxA9SSqX64hRDz8sjgjmuNslG29yGBIIOjL9Hq+jS O0rkUmJRZFO6LPJq384owx2XyPld+sMKN/JU7e/9AABGcEqiG5EBnMjy40LJ+B32Exhz rJZA== X-Gm-Message-State: AOJu0YxaEprfidH/AfR6sPAuJPS27cw5SQdDtcXjOGCLmj3RQbgRs+23 AeMv75zLYggHEzJS62aH1ui3OSMYZ4g5D54RD8c= X-Google-Smtp-Source: AGHT+IH6jydjHeK7ctNHr3EslIjS3Ujlnxuat8DiGyxKDLDLTJSu5RI00jIv5hmYAlchQqPKeVpGOxXO77qJJE4bLoA= X-Received: by 2002:a05:690c:4:b0:5ea:905d:6f4 with SMTP id bc4-20020a05690c000400b005ea905d06f4mr3603916ywb.50.1705290413656; Sun, 14 Jan 2024 19:46:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Sun, 14 Jan 2024 19:46:42 -0800 Message-ID: Subject: Re: [PATCH] libstdc++: atomic: Add missing clear_padding in __atomic_float constructor To: xndcn Cc: GCC Patches Content-Type: multipart/alternative; boundary="000000000000584ee2060ef3dd63" X-Spam-Status: No, score=-3021.1 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,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 List-Id: --000000000000584ee2060ef3dd63 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 7, 2024, 5:02 PM xndcn wrote: > Hi, I found __atomic_float constructor does not clear padding, > while __compare_exchange assumes it as zeroed padding. So it is easy to > reproducing a infinite loop in X86-64 with long double type like: > --- > -O0 -std=c++23 -mlong-double-80 > #include > #include > > #define T long double > int main() { > std::atomic t(0.5); > t.fetch_add(0.5); > float x = t; > printf("%f\n", x); > } > --- > > So we should add __builtin_clear_padding in __atomic_float constructor, > just like the generic atomic struct. > > regtested on x86_64-linux. Is it OK for trunk? > > --- > libstdc++: atomic: Add missing clear_padding in __atomic_float constructor. > > libstdc++-v3/ChangeLog: > > * include/bits/atomic_base.h: add __builtin_clear_padding in > __atomic_float constructor. > --- > libstdc++-v3/include/bits/atomic_base.h | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/libstdc++-v3/include/bits/atomic_base.h > b/libstdc++-v3/include/bits/atomic_base.h > index f4ce0fa53..d59c2209e 100644 > --- a/libstdc++-v3/include/bits/atomic_base.h > +++ b/libstdc++-v3/include/bits/atomic_base.h > @@ -1283,7 +1283,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > > constexpr > __atomic_float(_Fp __t) : _M_fp(__t) > - { } > + { > +#if __has_builtin(__builtin_clear_padding) > + if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Fp>()) > + __builtin_clear_padding(std::__addressof(_M_fp)); > +#endif > + } > > __atomic_float(const __atomic_float&) = delete; > __atomic_float& operator=(const __atomic_float&) = delete; > -- > 2.25.1 > Can you add a testcase? Thanks. H.J. > --000000000000584ee2060ef3dd63--