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 3B4E5385803E for ; Fri, 6 May 2022 18:22:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3B4E5385803E Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-201-ghNDzdx8NcKRE8_bIF090g-1; Fri, 06 May 2022 14:22:46 -0400 X-MC-Unique: ghNDzdx8NcKRE8_bIF090g-1 Received: by mail-qv1-f71.google.com with SMTP id m6-20020a0562141bc600b0045a8357224aso6552719qvc.12 for ; Fri, 06 May 2022 11:22:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=hT5NTx51hlhh4/cjIiC/E6zut99mZYpOZUybV91sjQE=; b=4FvaaxbdJYGtEMwzhni7E0QKYkidEPkFsQskqnee8Df/JZ3mqhOCBkROv/nlyQlOw4 ODSeaGwHeYXUVstMdmyt8Dkup6X0PzgA8V8wM6jGcs41HeIyLeLQy9eV7qEalV03lKbq s/yAS639Cmo1dNRl4TzrVe70V2b/dj2YT4uxIawAD2UE+4ZLxHJSZ6qEKg3UsHMbzPUQ H5NdqHz4ZMLX0tkCGGbcPnQpw8HD0jLWiJPxecoE7VDlo+BINqSBb+5kAxyoZaBcAmni zdMpCdarMqmTn/y/M/tbSAaBO2rTWsB4ACOrEqx5AjFB7ksNEaDlE8Ie98qmJR7Pk26O Vk4w== X-Gm-Message-State: AOAM533NN7GmzTqJQ4qgHn8LZJpPUua9fyNDJTp8YB73nnsdyoC3jjet jNrUSuqXXGTfh5uy7rHRvninA1dwYyx1rqJl9jtQbELwOa+jQTeKiUUWlaOVoB06r7Q2hmPOxqq gnxz02anOk6bECiEpmA== X-Received: by 2002:a05:620a:4727:b0:6a0:3036:8bfe with SMTP id bs39-20020a05620a472700b006a030368bfemr3409855qkb.239.1651861365277; Fri, 06 May 2022 11:22:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxR/PzYGz73G/RTOewW4O2gbz0FI93ry5HHs5kMzJ+G9OiIjz9zCxGmlV24FYvVcLu02z9dGg== X-Received: by 2002:a05:620a:4727:b0:6a0:3036:8bfe with SMTP id bs39-20020a05620a472700b006a030368bfemr3409837qkb.239.1651861364929; Fri, 06 May 2022 11:22:44 -0700 (PDT) Received: from [192.168.1.100] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id k80-20020a37a153000000b0069fc13ce1fdsm2828780qke.46.2022.05.06.11.22.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 May 2022 11:22:43 -0700 (PDT) Message-ID: Date: Fri, 6 May 2022 14:22:42 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH] c++: constexpr init of union sub-aggr w/ base [PR105491] To: Patrick Palka Cc: gcc-patches@gcc.gnu.org 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> From: Jason Merrill In-Reply-To: <48baf04b-9cb9-8668-cbb6-047eba1033d7@idea> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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 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 18:22:48 -0000 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? > 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+? 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. Jason