From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2B99F3858426 for ; Tue, 2 Nov 2021 07:50:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B99F3858426 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-306-L1x3Y5omOtaFYuSKlQqKcw-1; Tue, 02 Nov 2021 03:49:56 -0400 X-MC-Unique: L1x3Y5omOtaFYuSKlQqKcw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C686D802B61; Tue, 2 Nov 2021 07:49:55 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.172]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3347B6091B; Tue, 2 Nov 2021 07:49:55 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 1A27nqBO1018578 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 2 Nov 2021 08:49:52 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 1A27npvm1018577; Tue, 2 Nov 2021 08:49:51 +0100 Date: Tue, 2 Nov 2021 08:49:51 +0100 From: Jakub Jelinek To: Thomas Rodgers Cc: Jonathan Wakely , gcc Patches , libstdc++ , Thomas Rodgers Subject: Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange Message-ID: <20211102074951.GZ304296@tucnak> Reply-To: Jakub Jelinek References: <20210923180837.633173-1-rodgert@appliantology.com> <20210927141031.651313-1-rodgert@appliantology.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 07:50:03 -0000 On Mon, Nov 01, 2021 at 06:25:45PM -0700, Thomas Rodgers via Gcc-patches wrote: > + template > + constexpr bool > + __maybe_has_padding() > + { > +#if __has_builtin(__has_unique_object_representations) > + return !__has_unique_object_representations(_Tp) > + && !is_floating_point<_Tp>::value; > +#else > + return true; > +#endif I'm not sure I understand the && !is_floating_point<_Tp>::value. Yes, float and double will never have padding, but long double often will, e.g. on x86 or ia64 (but e.g. not on ppc, s390x, etc.). So, unless we want to play with numeric_limits, it should be either just return !__has_unique_object_representations(_Tp); or return !__has_unique_object_representations(_Tp) && (!is_floating_point<_Tp>::value || is_same<__remove_cv_t<_Tp>,long double>::value); or, with numeric_limits test numeric_limits<_Tp>::digits == 64 (but I'm sure Jonathan will not want including such a header dependency unless it is already included). Or I can always provide a new __builtin_clear_padding_p ... Jakub