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 2B3173858D3C for ; Thu, 16 Mar 2023 14:38:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2B3173858D3C 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=1678977510; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GHpfAc//dz6bHEgzIc5fP2aepzsyTYUZse/R4nrAPgA=; b=Umf2aUxLVOopec8SxG5GMK0rskxCqmKXyCXInYQKuVZz6+IJ5hSey2bnaAnuBmDct2Go82 IaGqpCWUGtD3VJRdyRFsYL/fvVMzGR6glBwNapzG5YANrlkcV7D5dNJsY5nZQ9rJHrRW2J ZO36Ym3EYT0fnt3IlTZcNykor6j8DDw= 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.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-451-KlvC3NbiO7mgiYF_kQu8sQ-1; Thu, 16 Mar 2023 10:38:29 -0400 X-MC-Unique: KlvC3NbiO7mgiYF_kQu8sQ-1 Received: by mail-qv1-f71.google.com with SMTP id v6-20020a0ccd86000000b005add90903d7so1154474qvm.14 for ; Thu, 16 Mar 2023 07:38:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678977509; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GHpfAc//dz6bHEgzIc5fP2aepzsyTYUZse/R4nrAPgA=; b=YY15QOhuxZn+5f/C0IAA0wHF7mvXmSSw/60BY4QeJXPDFOankKY9sNZo4RsmlEOHHz T1OKQdXQrqcNkK5/AINFh39/ggzaoNGmRIKEnq/Ozj0KCTxLeGisjNkHsld1NHPYwXPI MmbpNiIbyIoLSzy/DN71VI7X4Dvu+Qpcf2B4aOPgEfigLGBtPtHnHP2hJfqjIRFq0s4s ZyBYoD/1Id6YZdP7UVeKgdRy3GUTb1I0kiyuG+zdUjZoll+IGuFTJxL03oJteMHAsHRi QVlh2FS+UnGDf1LdWpWWNL2GE3x49bJuyNP+uXHl2Q++iKyuqdtHW6IMKyyH83/36m2Z GtWA== X-Gm-Message-State: AO0yUKUWjgDAe1JNQE32DU+FGiM0StnMbDbro4pxUXvHfGKAx+7awhLh E8xJ75Tj6TaFAGA6MnbRgI8Dsz7AOvbj1Ie27W+dHrq3qbAFl1r9tVW6gNBvCe3hYNyTkY/4kTs K9RGkgQWoI5YTJT8iaQ== X-Received: by 2002:a05:622a:1a25:b0:3b8:5057:377b with SMTP id f37-20020a05622a1a2500b003b85057377bmr6628651qtb.65.1678977509207; Thu, 16 Mar 2023 07:38:29 -0700 (PDT) X-Google-Smtp-Source: AK7set93WAAvr1ssBUkuLLeXMALlB+7Zvb+XwievlYBSjd3Km4bpDhkqeYhgsnS732h7JIQv1EcvGw== X-Received: by 2002:a05:622a:1a25:b0:3b8:5057:377b with SMTP id f37-20020a05622a1a2500b003b85057377bmr6628609qtb.65.1678977508822; Thu, 16 Mar 2023 07:38:28 -0700 (PDT) Received: from [192.168.1.108] (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 w7-20020ac86b07000000b003b9bca1e093sm5826677qts.27.2023.03.16.07.38.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Mar 2023 07:38:27 -0700 (PDT) Message-ID: Date: Thu, 16 Mar 2023 10:38:24 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] c++: noexcept and copy elision [PR109030] To: Patrick Palka Cc: Marek Polacek , GCC Patches References: <20230306235957.390533-1-polacek@redhat.com> <233db53c-67cb-37cf-92ef-620b3678d86f@idea> <5720dde1-3aae-0fc0-44b5-2d992951c55b@idea> From: Jason Merrill In-Reply-To: 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=-12.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,NICE_REPLY_A,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 3/16/23 10:09, Patrick Palka wrote: > On Wed, 15 Mar 2023, Patrick Palka wrote: > >> On Thu, 9 Mar 2023, Jason Merrill wrote: >> >>> On 3/9/23 14:32, Patrick Palka wrote: >>>> On Mon, 6 Mar 2023, Marek Polacek via Gcc-patches wrote: >>>> >>>>> When processing a noexcept, constructors aren't elided: build_over_call >>>>> has >>>>> /* It's unsafe to elide the constructor when handling >>>>> a noexcept-expression, it may evaluate to the wrong >>>>> value (c++/53025). */ >>>>> && (force_elide || cp_noexcept_operand == 0)) >>>>> so the assert I added recently needs to be relaxed a little bit. >>>>> >>>>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? >>>>> >>>>> PR c++/109030 >>>>> >>>>> gcc/cp/ChangeLog: >>>>> >>>>> * constexpr.cc (cxx_eval_call_expression): Relax assert. >>>>> >>>>> gcc/testsuite/ChangeLog: >>>>> >>>>> * g++.dg/cpp0x/noexcept77.C: New test. >>>>> --- >>>>> gcc/cp/constexpr.cc | 6 +++++- >>>>> gcc/testsuite/g++.dg/cpp0x/noexcept77.C | 9 +++++++++ >>>>> 2 files changed, 14 insertions(+), 1 deletion(-) >>>>> create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept77.C >>>>> >>>>> diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc >>>>> index 364695b762c..5384d0e8e46 100644 >>>>> --- a/gcc/cp/constexpr.cc >>>>> +++ b/gcc/cp/constexpr.cc >>>>> @@ -2869,7 +2869,11 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, >>>>> tree t, >>>>> /* We used to shortcut trivial constructor/op= here, but nowadays >>>>> we can only get a trivial function here with >>>>> -fno-elide-constructors. */ >>>>> - gcc_checking_assert (!trivial_fn_p (fun) || !flag_elide_constructors); >>>>> + gcc_checking_assert (!trivial_fn_p (fun) >>>>> + || !flag_elide_constructors >>>>> + /* We don't elide constructors when processing >>>>> + a noexcept-expression. */ >>>>> + || cp_noexcept_operand); >>>> >>>> It seems weird that we're performing constant evaluation within an >>>> unevaluated operand. Would it make sense to also fix this a second way >>>> by avoiding constant evaluation from maybe_constant_init when >>>> cp_unevaluated_operand && !manifestly_const_eval, like in >>>> maybe_constant_value? >>> >>> Sounds good. >> >> Hmm, while working on this I noticed we currently don't reject a version of >> g++.dg/cpp2a/constexpr-inst1.C that list initializes an aggregate instead of >> int (ever since r12-4425-g1595fe44e11a96): >> >> struct A { int m; }; >> template constexpr int f() { return T::value; } >> template void h(decltype(A{B ? f() : 0})); // was int{...} >> template void h(...); >> void x() { >> h(0); // OK? >> } >> >> ISTM we should instantiate f here for the same reason we do in the >> original version of the testcase, and for that to happen we need to >> pass manifestly_const_eval=true in massage_init_elt. Does that seem >> reasonable? >> > > FWIW the reason this came up is because I tried contriving a testcase > for the aforementioned maybe_constant_init change, and I came up with: > > struct __as_receiver { > int empty_env; > }; > > template > constexpr int f(T t) { > return t.fail; > }; > > using type = decltype(__as_receiver{f(0)}); // OK, f no longer instantiated > > which we used to reject and afterwards accept. But since the elements > of an initializer list are potentially constant evaluated, I wonder if > that that means f should be instantiated here after all despite the > unevaluated context? The relevant section of the standard would seem to be https://eel.is/c++draft/expr.const#20 ; an immediate subexpression of a braced-init-list is potentially constant-evaluated even though it isn't potentially-evaluated or manifestly constant-evaluated. It seems like the call to fold_non_dependent_expr in check_narrowing ought to cause instantiation in this case, why doesn't it? > Here's the full patch for reference: > > -- >8 -- > > Subject: [PATCH] c++: maybe_constant_init and unevaluated operands [PR109030] > > This testcase in this PR (already fixed by r13-6526-ge4692319fd5fc7) > illustrates that maybe_constant_init can be called on an unevaluated > operand (from massage_init_elt), so this entry point should limit > constant evaluation in that case, like maybe_constant_value does. > > PR c++/109030 > > gcc/cp/ChangeLog: > > * constexpr.cc (maybe_constant_init_1): For an unevaluated > non-manifestly-constant operand, don't constant evaluate > and instead call fold_to_constant. > > gcc/testsuite/ChangeLog: > > * g++.dg/cpp0x/decltype83.C: New test. > --- > gcc/cp/constexpr.cc | 2 ++ > gcc/testsuite/g++.dg/cpp0x/decltype83.C | 14 ++++++++++++++ > 2 files changed, 16 insertions(+) > create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype83.C > > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc > index 8683c00596a..f325af375c8 100644 > --- a/gcc/cp/constexpr.cc > +++ b/gcc/cp/constexpr.cc > @@ -8795,6 +8795,8 @@ maybe_constant_init_1 (tree t, tree decl, bool allow_non_constant, > && (TREE_STATIC (decl) || DECL_EXTERNAL (decl))); > if (is_static) > manifestly_const_eval = true; > + if (cp_unevaluated_operand && !manifestly_const_eval) > + return fold_to_constant (t); > t = cxx_eval_outermost_constant_expr (t, allow_non_constant, !is_static, > mce_value (manifestly_const_eval), > false, decl); > diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype83.C b/gcc/testsuite/g++.dg/cpp0x/decltype83.C > new file mode 100644 > index 00000000000..17005a92eb5 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp0x/decltype83.C > @@ -0,0 +1,14 @@ > +// { dg-do compile { target c++11 } } > + > +struct __as_receiver { > + int empty_env; > +}; > + > +template > +constexpr int f(T t) { > + return t.fail; > +}; > + > +int main() { > + using type = decltype(__as_receiver{f(0)}); // OK, f not instantiated > +}