From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id 223663858C27 for ; Wed, 3 Nov 2021 03:06:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 223663858C27 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=twrodgers.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=twrodgers.com Received: by mail-oi1-x234.google.com with SMTP id bo10so1776220oib.5 for ; Tue, 02 Nov 2021 20:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twrodgers-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FwmIGhTKkmk4W+LYxqz04VhDZS7axtHKiNmz8Ip0SJs=; b=MhUBAPfkHTU3lLhSLwaxMo1GR4v1h+d55tEmVX/kXQrPMU/WES16O7nZ8RD22rDJIS dr4841UFUdYiqyezIxrdzpVaZCUwZy8I1uHGEFjQVlNxGS43imLUpcRBpLECSPVCGZen OoZs5nMx0osfIaF0JMjQh00X0cGp0kIOr/a5ngEGIpy/3wKIZ33Y29LLgBNjGEGoDhz9 i7MccgGxwcmXYU1RiQLUPtdwT+hz1qp7WvbD19305Dx+kDFSCAj9dd8UHXtZSu1v6gmH 4vj3dmq3QiB3au7q9XrhmE6NNkRqx3pa70RkFhj2fP9MdGDSKEkFgI1HfRwddlABlfEI iFWA== 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=FwmIGhTKkmk4W+LYxqz04VhDZS7axtHKiNmz8Ip0SJs=; b=1fJCP7IH8EZ/s1TAGvFxqccQ2cKdl1taIttf075JnfNzsqHSw2NIjBsJk7tXsojYdT o8w8NiivpbfgiG/YOo84OLPGvPxxQXJn/S6O1eOW9zzvds1QViIjwbihezwZMZzyOMyn b3yJcAb5Dz3hAZG3Rv9J3/MYv4ttd6phthO7THW5aCx2/hJOuUCMU78tfiAHd2kGSxnn LN0amO11nQgFjzOW4Irzmnbyv13Fg+8aooPVrpLfg5JRQAAmAuHtTYeUFPD/Vq1bgOjD FU2Op8UyYpBNnmwF1IUhnLqX0VEJUtMzI77c1Zzo4TCP42jDEWtnYsmktAV0MEuSuPp8 UkYw== X-Gm-Message-State: AOAM531Sx5/1mWomKCorBbnNyOi3cEWtN7oDg1wIcvDsk/keP3jP8n6s N2wBNbGEDiaaTTwWVFSuaO2cVM1cbgtWrLsOpNmDrQ== X-Google-Smtp-Source: ABdhPJwnaSM9Em3VJOyez6sbqJJLbma1Ndj4aIUYMrryjcxpYidqUn2XnEKwafHzOGxvMkutFXk3HzxylVnonjsWRuM= X-Received: by 2002:a05:6808:10d2:: with SMTP id s18mr8583675ois.30.1635908816589; Tue, 02 Nov 2021 20:06:56 -0700 (PDT) MIME-Version: 1.0 References: <20210923180837.633173-1-rodgert@appliantology.com> <20210927141031.651313-1-rodgert@appliantology.com> <20211102074951.GZ304296@tucnak> In-Reply-To: <20211102074951.GZ304296@tucnak> From: Thomas Rodgers Date: Tue, 2 Nov 2021 20:06:45 -0700 Message-ID: Subject: Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange To: Jakub Jelinek Cc: Jonathan Wakely , Thomas Rodgers , gcc Patches , "libstdc++" X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Wed, 03 Nov 2021 03:06:58 -0000 This version of the patch specifically doesn=E2=80=99t deal with long doubl= e. Mostly looking for Jonathan=E2=80=99s review to ensure his previous feedbac= k is addressed. I plan to rev the patch to handle long doubles after some further discussion with you and Jonathan. On Tue, Nov 2, 2021 at 12:49 AM Jakub Jelinek wrote: > 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 =3D=3D 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 > >