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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 332523870872 for ; Thu, 27 Aug 2020 11:22:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 332523870872 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-288-TZaVjcq1N6qGz2trk7KuZQ-1; Thu, 27 Aug 2020 07:22:52 -0400 X-MC-Unique: TZaVjcq1N6qGz2trk7KuZQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2B73883DCAE; Thu, 27 Aug 2020 11:22:51 +0000 (UTC) Received: from localhost (unknown [10.33.36.61]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7C9F7757DF; Thu, 27 Aug 2020 11:22:49 +0000 (UTC) Date: Thu, 27 Aug 2020 12:22:49 +0100 From: Jonathan Wakely To: Jakub Jelinek Cc: Jason Merrill , Martin Jambor , Richard Biener , Iain Buclaw , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: Add __builtin_bit_cast to implement std::bit_cast [PR93121] Message-ID: <20200827112249.GT3400@redhat.com> References: <20200730145732.GZ2363@tucnak> <20200731081911.GE2363@tucnak> <20200731095446.GU3400@redhat.com> <20200731100625.GF2363@tucnak> <4f2a1527-f7f3-37e9-1d56-4794f9ede49b@redhat.com> <20200827100613.GI2961@tucnak> <20200827104656.GJ2961@tucnak> <20200827110659.GS3400@redhat.com> <20200827111728.GK2961@tucnak> MIME-Version: 1.0 In-Reply-To: <20200827111728.GK2961@tucnak> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spam-Status: No, score=-9.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 11:22:55 -0000 On 27/08/20 13:17 +0200, Jakub Jelinek wrote: >On Thu, Aug 27, 2020 at 12:06:59PM +0100, Jonathan Wakely wrote: >> On 27/08/20 12:46 +0200, Jakub Jelinek wrote: >> > On Thu, Aug 27, 2020 at 12:06:13PM +0200, Jakub Jelinek via Gcc-patches wrote: >> > >> > Oops, rewrote the testcase from __builtin_bit_cast to std::bit_cast without >> > adjusting the syntax properly. >> > Also, let's not use bitfields in there, as clang doesn't support those. >> > So, adjusted testcase below. clang++ rejects all 6 of those, but from what >> > you said, I'd expect that u and z should be well defined. >> > >> > #include >> > >> > struct S { short a; int b; }; >> > struct T { int a, b; }; >> > >> > constexpr int >> > foo () >> > { >> > S a = S (); >> > S b = { 0, 0 }; >> > S c = a; >> > S d; >> > S e; >> > d = a; >> > e = S (); >> > int u = std::bit_cast (a).a; // Is this well defined due to value initialization of a? >> >> The standard says that padding bits in the bit_cast result are >> unspecified, so I don't think they have to be copied even if the >> source object was zero-initialized and has all-zero padding bits. > >My understanding of >"Padding bits of the To object are unspecified." >is that one shouldn't treat the result of std::bit_cast as if it was e.g. >value initialization followed by member-wise assignment. >But it doesn't say anything about padding bits in the From object. >In the above testcase, T has no padding bits, only S has them. Doh, yes, sorry. >I think the "Padding bits of the To object are unspecified." should be about: > T t = { 0, 0 }; > int s = std::bit_cast (std::bit_cast (t)).a; >being UB, that one can't expect the padding bits in S to have a particular >value. > > Jakub