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 361103857C46 for ; Wed, 2 Sep 2020 21:52:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 361103857C46 Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-402--GfPNR9dMYevDy7gc-1wdg-1; Wed, 02 Sep 2020 17:52:07 -0400 X-MC-Unique: -GfPNR9dMYevDy7gc-1wdg-1 Received: by mail-qt1-f198.google.com with SMTP id g12so26553qtx.7 for ; Wed, 02 Sep 2020 14:52:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y8n4ulQFPMnW6iQr0/sRWr3Ope9nn9ieDbOWbf5VtHU=; b=s9ad5Dsfha1jR+LDTs8arezGyunZmO1CSD8qF1ZwnXLp5HlKIIYioaKJshX2tEHaZb sS8QLFjsjpceZXiIY8tQQgJHaKw9YJkOvsxJBrK0XH5xFhlDcer20lcNCfRwil4qwGUR zkRvTTPo8n8XG4ysFTlAWTmw6X3oZuLX2DzxnhJkV/tyQ8lS2E/OHTp5xUasd0k43N28 AlpnaBSyMKeDm7zZBsomB8zziVdY5J/ndFnPEl6ZiDUqDyIS1aWV8IsQAkCHRQJq1c5v RiXvz2jKEwqYSPaUSmczXkcy/cdMzI12DAcdvOZNiPCA8UqeOPO9a/bQhJaUJlICPwq4 Y0zg== X-Gm-Message-State: AOAM531YG/XOFPsReGayYhCdVFEAYnz3zAiHV9cAQjymPN0GueefcQNI 7yMBwchfj/J8XTjC54H2Sze8V+WP2axXqcOy+MOoB8Mwj3rGbg3gQ0WXRXZxZNJVszBgp+DSwPj iYatyL3fPkq97g1lK5A== X-Received: by 2002:a37:78b:: with SMTP id 133mr92016qkh.107.1599083526253; Wed, 02 Sep 2020 14:52:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyHFMLI1+Mvakz30/Bx7rSz1fJ5jsVhXegIiWw1xyTMRDZgzzEARFxw6kC3ft7EBDYz9nS5Xg== X-Received: by 2002:a37:78b:: with SMTP id 133mr92003qkh.107.1599083525900; Wed, 02 Sep 2020 14:52:05 -0700 (PDT) Received: from [192.168.1.148] (209-6-216-142.s141.c3-0.smr-cbr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.216.142]) by smtp.gmail.com with ESMTPSA id j190sm749907qkd.22.2020.09.02.14.52.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Sep 2020 14:52:04 -0700 (PDT) Subject: Re: [PATCH] c++: Add __builtin_bit_cast to implement std::bit_cast [PR93121] To: Richard Biener , Jakub Jelinek Cc: Martin Jambor , Iain Buclaw , Jonathan Wakely , gcc-patches@gcc.gnu.org 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> From: Jason Merrill Message-ID: Date: Wed, 2 Sep 2020 17:52:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, 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: Wed, 02 Sep 2020 21:52:14 -0000 On 8/27/20 6:19 AM, Richard Biener wrote: > On Thu, 27 Aug 2020, 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. > > Note we've basically settled on that SRA needs to copy padding and that > GIMPLE copies all bytes for aggregate copies and thus > > x = {} > > is equivalent to a memset. > >> 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. > > Now indeed the gimplifier will turn a aggregate CTOR initialization > to memberwise init without caring for padding. Which means GENERIC > has the less strict semantics and we indeed would need some CTOR flag > to tell whether padding is implicitely zero or undefined? CONSTRUCTOR_NO_CLEARING would seem to already mean that, but the C++ front end uses it just to indicate whether some fields are uninitialized. I suppose C++ could use a LANG_FLAG for that instead of the generic flag. >> 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? >> int x = std::bit_cast (T, d).a; // Similarly for default copy assignment operators... >> int y = std::bit_cast (T, e).a; // And this too? >> int z = std::bit_cast (T, S ()).a; // This one is well defined? >> return u + v + w + x + y + z; >> } >> >> constexpr int x = foo (); >> >> Jakub >> >> >