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.129.124]) by sourceware.org (Postfix) with ESMTPS id 2CAF13858D28 for ; Fri, 6 May 2022 19:24:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2CAF13858D28 Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-395-075TcPoaOAy4CILId8TtjQ-1; Fri, 06 May 2022 15:24:05 -0400 X-MC-Unique: 075TcPoaOAy4CILId8TtjQ-1 Received: by mail-qv1-f72.google.com with SMTP id bz15-20020ad44c0f000000b0045641657fd2so6650916qvb.22 for ; Fri, 06 May 2022 12:24:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=G9O3YqGIiH1wj0A9KenSJ+VnPSacGuckr5uZLeFdmTM=; b=6IEY+OCu8jACs/HjlNDUByfoI1fFlkJ+ClESnAvHKUb5bGWyNs1+9cHiDa+ueCEX5q z/bdUG03Q6VMO8HpCYuThL4el136hbdjZF9TOrzxEen2j5d5PIlzQa+C1Ab+Be96aiyT +0GQXFFv2alMI45bvPM67KAGwN+cnIFgWKYUDTuuEn/FX61KF3f3batHqrDeLPXcqaix 5FpmKlwLrDj88COUYqKxWzvCw0SiIdmK/R0Iyf75tz2sLz8mP5cnVUOaGEo3hqC4/nU5 d8yzWR9S1WaLK/OVBWTNpOumLwqs4Z46tZFgTpjxzcXpSixo3cAs3owHx8qeU8+vawk6 4Seg== X-Gm-Message-State: AOAM5321rYuP1YOWLTBsN4yN4SAYzzO6PiUHm0QJeUz8PqH9s8GWHrC2 DWjEZb+PHfWMzwlMoSw72VWcBILJ0zgtDQh4mYvKwZ6yHT0Tm9YWf4D1sLqPkAOWzfArLwDCNKV X/o5cSo+f7rQwIx2irQ== X-Received: by 2002:a05:622a:351:b0:2f3:9508:913d with SMTP id r17-20020a05622a035100b002f39508913dmr4264854qtw.591.1651865045129; Fri, 06 May 2022 12:24:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz9fLV3xMrm+89VqKpwizT+nD63VpVcBcZORwgX/YvYv/2OAgtOZbwvsxQFAwFWuE5e3Dov5g== X-Received: by 2002:a05:622a:351:b0:2f3:9508:913d with SMTP id r17-20020a05622a035100b002f39508913dmr4264830qtw.591.1651865044871; Fri, 06 May 2022 12:24:04 -0700 (PDT) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id b14-20020a05620a0cce00b0069fd2a10ef7sm2732527qkj.100.2022.05.06.12.24.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 May 2022 12:24:04 -0700 (PDT) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Fri, 6 May 2022 15:24:03 -0400 (EDT) To: Jason Merrill cc: Patrick Palka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: constexpr init of union sub-aggr w/ base [PR105491] In-Reply-To: Message-ID: References: <20220506152232.2843007-1-ppalka@redhat.com> <659fd0c4-5fa7-147d-9b97-bebf06ae7c23@redhat.com> <7ab4b646-bade-97b0-8083-c392cf37ea49@idea> <48baf04b-9cb9-8668-cbb6-047eba1033d7@idea> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Fri, 06 May 2022 19:24:08 -0000 On Fri, 6 May 2022, Jason Merrill wrote: > On 5/6/22 14:00, Patrick Palka wrote: > > On Fri, 6 May 2022, Patrick Palka wrote: > > > > > On Fri, 6 May 2022, Jason Merrill wrote: > > > > > > > On 5/6/22 11:22, Patrick Palka wrote: > > > > > Here ever since r10-7313-gb599bf9d6d1e18, > > > > > reduced_constant_expression_p > > > > > in C++11/14 is rejecting the marked sub-aggregate initializer (of type > > > > > S) > > > > > > > > > > W w = {.D.2445={.s={.D.2387={.m=0}, .b=0}}} > > > > > ^ > > > > > > > > > > ultimately because said initializer has CONSTRUCTOR_NO_CLEARING set, > > > > > and > > > > > so the function proceeds to verify that all fields of S are > > > > > initialized. > > > > > And before C++17 we don't expect to see base class fields (since > > > > > next_initializable_field skips over the), so the base class > > > > > initializer > > > > > causes r_c_e_p to return false. > > > > > > > > That seems like the primary bug. I guess r_c_e_p shouldn't be using > > > > next_initializable_field. Really that function should only be used for > > > > aggregates. > > > > > > I see, I'll try replacing it in r_c_e_p. Would that be in addition to > > > or instead of the clear_no_implicit_zero approach? > > > > I'm testing the following, which uses a custom predicate instead of > > next_initializable_field in r_c_e_p. > > Let's make it a public predicate, not internal to r_c_e_p. Maybe it could be > next_subobject_field, and the current next_initializable_field change to > next_aggregate_field? Will do. > > > Looks like the inner initializer {.D.2387={.m=0}, .b=0} is formed during > > the subobject constructor call: > > > > V::V (&((struct S *) this)->D.2120); > > > > after the evaluation of which, 'result' in cxx_eval_call_expression is NULL > > (presumably because it's a CALL_EXPR, not AGGR_INIT_EXPR?): > > > > /* This can be null for a subobject constructor call, in > > which case what we care about is the initialization > > side-effects rather than the value. We could get at the > > value by evaluating *this, but we don't bother; there's > > no need to put such a call in the hash table. */ > > result = lval ? ctx->object : ctx->ctor; > > > > so we end up not calling clear_no_implicit_zero for the inner initializer > > directly. We only call clear_no_implicit_zero after evaluating the > > AGGR_INIT_EXPR for outermost initializer (of type W). > > Maybe for constructors we could call it on ctx->ctor instead of result, or > call r_c_e_p in C++20+? But both ctx->ctor and ->object are NULL during a subobject constructor call (since we apparently clear these fields when entering a STATEMENT_LIST): So I tried instead obtaining the constructor by evaluating new_obj via --- a/gcc/cp/constexpr.cc +++ b/gcc/cp/constexpr.cc @@ -2993,6 +2988,9 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree t, in order to detect reading an unitialized object in constexpr instead of value-initializing it. (reduced_constant_expression_p is expected to take care of clearing the flag.) */ + if (new_obj && DECL_CONSTRUCTOR_P (fun)) + result = cxx_eval_constant_expression (ctx, new_obj, /*lval=*/false, + non_constant_p, overflow_p); if (TREE_CODE (result) == CONSTRUCTOR && (cxx_dialect < cxx20 || !DECL_CONSTRUCTOR_P (fun))) but that seems to break e.g. g++.dg/cpp2a/constexpr-init12.C because after the subobject constructor call S::S (&((struct W *) this)->s, NON_LVALUE_EXPR <8>); the constructor for the subobject a.s in new_obj is still completely missing (I suppose because S::S doesn't initialize any of its members) so trying to obtain it causes us to complain too soon from cxx_eval_component_reference: constexpr-init12.C:16:24: in ‘constexpr’ expansion of ‘W(42)’ constexpr-init12.C:10:22: in ‘constexpr’ expansion of ‘((W*)this)->W::s.S::S(8)’ constexpr-init12.C:16:24: error: accessing uninitialized member ‘W::s’ 16 | constexpr auto a = W(42); // { dg-error "not a constant expression" } | ^ > > It does seem dubious that we would clear the flag on an outer ctor when it's > still set on an inner ctor, should probably add an assert somewhere. Makes sense, not sure where the best place would be.. > > Jason > >