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 EDF343858D20 for ; Fri, 3 Feb 2023 18:56:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EDF343858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675450568; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VPWl1XCpL5/OXykAzUCrhqDg5vtyo++IaEURCRomcas=; b=hpXuzc6ZSB5T5a0SG/TYFhdedixrmDD2Fp4Gcaun6MTn8FGQiO9rGp3GZVT2YkW7kY9NJO NC73CkyMbopkeQVb/SmGbBK1h4Yi7OfDpJ6O7QmdkbwMwtJPT6gInyg0Xd9Rciv/yb+mLN oB+nLZJkbk3Fl0Idsk3C7NVys8UR55g= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-331-L76qbjlmPFKBVrQdTgNJ-Q-1; Fri, 03 Feb 2023 13:56:07 -0500 X-MC-Unique: L76qbjlmPFKBVrQdTgNJ-Q-1 Received: by mail-qt1-f197.google.com with SMTP id c16-20020ac85190000000b003b841d1118aso3088974qtn.17 for ; Fri, 03 Feb 2023 10:56:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VPWl1XCpL5/OXykAzUCrhqDg5vtyo++IaEURCRomcas=; b=fq3V5A9t3zuOvIrLQRnXl8gp54YTf2AtdSZZhVLdtaYJg0dn9dICMYC+lS4RGHAssx v0k2PTLP08eiTeAVYuhgdMTPQM+QAa2QgAoiElmTzUDjPUiyzCz5zxnOjxepFomMBEhY S0cDjVdUOZjAVQg8ZWFEOOTT8uGAfoNPb+l/LzbaGxnuhSKxfIXXZ/5xp5GdTiCKvZyq mp8/w1HpCUY7rKYbVU+GOwNnPXYefTbvEXeb0Z28XFde8oPerRPBbmG/YcjmDKenZMsc Y3KGaVm3gPRUoaFTD5Lbg2H/OPM4gR2JY1lLcRmGWiUncTsUbzVpiFGWlPXo+dqw/Wcm LHUw== X-Gm-Message-State: AO0yUKVacmNe4BZGFTukiploqG7wDvg3AI2tAVHondLVN0i6WwIETAjI KWX7cT+oWps5SgyJHfhiZM3FCxzS3qeads/JaPivK+crIOUXEqbvkHBfvtK80D5wi8rqd8H9ild Z0gxVISDHaU/tWKXfIw== X-Received: by 2002:ac8:5c55:0:b0:3b8:674c:6c18 with SMTP id j21-20020ac85c55000000b003b8674c6c18mr21194278qtj.45.1675450566622; Fri, 03 Feb 2023 10:56:06 -0800 (PST) X-Google-Smtp-Source: AK7set+JXUT8SzxU1jml4PI7BoOia+EMvMvcOQzGKrnNOSBic+/KA9uTB5QQqZ25IqIp3Fay/S7bPQ== X-Received: by 2002:ac8:5c55:0:b0:3b8:674c:6c18 with SMTP id j21-20020ac85c55000000b003b8674c6c18mr21194243qtj.45.1675450566307; Fri, 03 Feb 2023 10:56:06 -0800 (PST) Received: from redhat.com (2603-7000-9500-34a5-0000-0000-0000-1db4.res6.spectrum.com. [2603:7000:9500:34a5::1db4]) by smtp.gmail.com with ESMTPSA id dl10-20020a05620a1d0a00b007242a18ee8asm2269272qkb.128.2023.02.03.10.56.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Feb 2023 10:56:05 -0800 (PST) Date: Fri, 3 Feb 2023 13:56:04 -0500 From: Marek Polacek To: Jason Merrill Cc: GCC Patches Subject: Re: [PATCH v2] c++: wrong error with constexpr array and value-init [PR108158] Message-ID: References: <20230131023549.454983-1-polacek@redhat.com> <48936556-7f40-1b53-672c-b51cac05646f@redhat.com> <26eb8d60-3679-2dfc-ed9e-2ae85c1597bf@redhat.com> MIME-Version: 1.0 In-Reply-To: <26eb8d60-3679-2dfc-ed9e-2ae85c1597bf@redhat.com> User-Agent: Mutt/2.2.9 (2022-11-12) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.6 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_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Feb 03, 2023 at 01:53:48PM -0500, Jason Merrill wrote: > On 2/3/23 13:08, Marek Polacek wrote: > > On Thu, Feb 02, 2023 at 05:29:44PM -0500, Jason Merrill wrote: > > > On 1/30/23 21:35, Marek Polacek wrote: > > > > In this test case, we find ourselves evaluating 't' which is > > > > ((const struct carray *) this)->data_[VIEW_CONVERT_EXPR(index)] > > > > in cxx_eval_array_reference. ctx->object is non-null, a RESULT_DECL, so > > > > we replace it with 't': > > > > > > > > new_ctx.object = t; // result_decl replaced > > > > > > > > and then we go to cxx_eval_constant_expression to evaluate an > > > > AGGR_INIT_EXPR, where we end up evaluating an INIT_EXPR (which is in the > > > > body of the constructor for seed_or_index): > > > > > > > > ((struct seed_or_index *) this)->value_ = NON_LVALUE_EXPR <0> > > > > > > > > whereupon in cxx_eval_store_expression we go to the probe loop > > > > where the 'this' is evaluated to > > > > > > > > ze_set.tables_.first_table_.data_[0] > > > > > > > > so the 'object' is ze_set, but that isn't in ctx->global->get_value_ptr > > > > so we fail with a bogus error. ze_set is not there because it comes > > > > from a different constexpr context (it's not in cv_cache either). > > > > > > > > The problem started with r12-2304 where I added the new_ctx.object > > > > replacement. That was to prevent a type mismatch: the type of 't' > > > > and ctx.object were different. > > > > > > > > It seems clear that we shouldn't have replaced ctx.object here. > > > > The cxx_eval_array_reference I mentioned earlier is called from > > > > cxx_eval_store_expression: > > > > 6257 init = cxx_eval_constant_expression (&new_ctx, init, vc_prvalue, > > > > 6258 non_constant_p, overflow_p); > > > > which already created a new context, whose .object we should be > > > > using unless, for instance, INIT contained a.b and we're evaluating > > > > the 'a' part, which I think was the case for r12-2304; in that case > > > > ctx.object has to be something different. > > > > > > > > A relatively safe fix should be to check the types before replacing > > > > ctx.object, as in the below. > > > > > > Agreed. I'm trying to understand when the replacement could ever make > > > sense, since 't' is not the target, it's the initializer. The replacement > > > comes from Patrick's fix for 98295, but that testcase no longer hits that > > > code (likely due to changes in empty class handling). > > > > > > If you add a gcc_checking_assert (false) to the replacement, does anything > > > trip it? > > > > It would trip in constexpr-101371.C, added in r12-2304. BUT, and I would > > have sworn that it ICEd when I tried, it's not necessary anymore. So it > > looks like we can simply remove the new_ctx.object line. At least for > > trunk, maybe 12 too. > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > OK, thanks. Let's go with your original patch for 11/12. Will do, thanks. I think I'll wait for a few days before backporting. Marek