From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 866B1384607A for ; Thu, 27 Aug 2020 10:59:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 866B1384607A 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-58-yaanlv38OFm8DKw6jDkyWg-1; Thu, 27 Aug 2020 06:59:07 -0400 X-MC-Unique: yaanlv38OFm8DKw6jDkyWg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E19E118A2240; Thu, 27 Aug 2020 10:59:05 +0000 (UTC) Received: from localhost (unknown [10.33.36.61]) by smtp.corp.redhat.com (Postfix) with ESMTP id 795C9747BD; Thu, 27 Aug 2020 10:59:05 +0000 (UTC) Date: Thu, 27 Aug 2020 11:59:04 +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: <20200827105904.GR3400@redhat.com> References: <20200718185056.GN2363@tucnak> <0dda7918-cc7f-3f3f-64c0-34896ef9e15d@redhat.com> <20200730145732.GZ2363@tucnak> <20200731081911.GE2363@tucnak> <20200731095446.GU3400@redhat.com> <20200731100625.GF2363@tucnak> <4f2a1527-f7f3-37e9-1d56-4794f9ede49b@redhat.com> <20200827100613.GI2961@tucnak> MIME-Version: 1.0 In-Reply-To: <20200827100613.GI2961@tucnak> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0.002 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, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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 10:59:14 -0000 On 27/08/20 12:06 +0200, Jakub Jelinek wrote: >On Fri, Jul 31, 2020 at 04:28:05PM -0400, Jason Merrill via Gcc-patches wrote: >> On 7/31/20 6:06 AM, Jakub Jelinek wrote: >> > On Fri, Jul 31, 2020 at 10:54:46AM +0100, Jonathan Wakely wrote: >> > > > Does the standard require that somewhere? Because that is not what the >> > > > compiler implements right now. >> > > >> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78620 >> > >> > But does that imply that all CONSTRUCTORs without CONSTRUCTOR_NO_CLEARING >> > need to be treated that way? I mean, aren't such CONSTRUCTORs used also for >> > other initializations? >> >> Yes, they are also used to represent constant values of classes that are >> initialized by constexpr constructor. >> >> > And, are the default copy constructors or assignment operators supposed to >> > also copy the padding bits, or do they become unspecified again through >> > that? >> >> For a non-union class, a defaulted copy is defined as memberwise copy, not a >> copy of the entire object representation. So I guess strictly speaking the >> padding bits do become unspecified. But I think if the copy is trivial, in >> practice all implementations do copy the object representation; perhaps the >> specification should adjust accordingly. > >Sorry for not responding earlier. I think at least in GCC there is no >guarantee the copying is copying the object representation rather than >memberwise copy, both are possible, depending e.g. whether SRA happens or >not. > >So, shouldn't we have a new CONSTRUCTOR flag that will represent whether >padding bits are cleared or not and then use it e.g. in the gimplifier? >Right now the gimplifier only adds first zero initialization if >CONSTRUCTOR_NO_CLEARING is not set and some initializers are not present, >so if there is a new flag, we'd need to in that case find out if there are >any padding bits and do the zero initialization in that case. >A question is if GIMPLE var = {}; statement (empty CONSTRUCTOR) is handled >as zero initialization of also the padding bits, or if we should treat it >that way only if the CONSTRUCTOR on the rhs has the new bit set and e.g. >when lowering memset 0 into var = {}; set the bit too. >From what I understood on IRC, D has similar need for zero initialization of >padding. > >In the testcase below, what is and what is not UB? > >#include > >struct S { int a : 31; 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 (T, a).a; // Is this well defined due to value initialization of a? > int v = std::bit_cast (T, b).a; // But this is invalid, right? There is no difference in the IL though. > int w = std::bit_cast (T, c).a; // And this is also invalid, or are default copy ctors required to copy padding bits? They are not required to. It does a memberwise copy of the bases and members. Padding is not copied. > int x = std::bit_cast (T, d).a; // Similarly for default copy assignment operators... Same again, memberwise assignment of the bases and members. I'm not sure whether the previous values of padding bits has to be preserved though. If the LHS was zero-initialized (so its padding bits were zeroed) and you assign to it, I don't see anything that allows the padding bits to change. But I don't think the intention is to forbid using memcpy for trivial assignments, and that would copy padding bits. > int y = std::bit_cast (T, e).a; // And this too? Yes. I don't think e = S() is required to change the padding bits of e to be copies of the zero bits in S(), so they are unspecified after that assignment, and after the bit_cast. > int z = std::bit_cast (T, S ()).a; // This one is well defined? Yes, I think so. > return u + v + w + x + y + z; >} > >constexpr int x = foo (); > > Jakub