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 296F83858D35 for ; Thu, 16 Mar 2023 15:59:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 296F83858D35 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=1678982378; 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=ele9+5ftKgOA/FK17msBtjyByKCTqdQZ9Oxbq+4BCbc=; b=KLhkN4OcG8/euFrrHzfrmPlyZCbJ5wowEkxH5e3ISJoZ9v25BJ8ZXQju5+f42m738s2qXT dIr+Wgv5Qg4bIgWyWSmMzwiHbp7AdEqSTMbEhuuDHhvzkPfuW1urYnSiIBprpcUyKyyem7 v+hWSwlcTX2uYLlnp4Hf8iE1iJSvlPU= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-315-ltYeZS0WNkiS38AD_BrDXA-1; Thu, 16 Mar 2023 11:59:37 -0400 X-MC-Unique: ltYeZS0WNkiS38AD_BrDXA-1 Received: by mail-qv1-f70.google.com with SMTP id z14-20020a0cd78e000000b005adc8684170so1297212qvi.3 for ; Thu, 16 Mar 2023 08:59:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678982377; 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=ele9+5ftKgOA/FK17msBtjyByKCTqdQZ9Oxbq+4BCbc=; b=T3VaiUI5rmW/At3te4/fHlsZp8m5YgiNsgrlCVRdFfgQN7lLU4RxSRoU5bcQhk6GYv yhdkU/oFlaN8Xtggy0fmCXbGvLkYKUQPskSC081PxwQT1OaEOn7KNsl56aD7CdNiyTSu K4JhHCRZC2sMdepb8W/LWSIkD89FCmf41UL8BhrCuZ0r80NZuNuqPLwk2XmUTLPOPffK XLbkLE2KOc/tRWxGU8BoN0FKvBwGOwKdSw6RMMh5+X61AgrSC3A8MGHbSgIpuGp6Sm1F 22SXgNQ9IYaWx947CtpqF77bSVGblrA9X1NsT7Lvn9qBHy29GksXRWQ0vbQca+AHgK8k rEig== X-Gm-Message-State: AO0yUKULtjskcv0SYWpaYwYp/f8+pgL2YvWJFR67btmJxSq3mmBCvA10 kmzZMt5d1AKG+MmT1gEI+9LlG64ElE2B/fXdcSy94xABcFusqH07FXO9Y2Iwog2k62BrIwh3KEy VgZI7OlDeYcN9UuT7tU2CN+ANnA== X-Received: by 2002:a05:622a:1486:b0:3b8:6cb0:8d28 with SMTP id t6-20020a05622a148600b003b86cb08d28mr7278274qtx.6.1678982376753; Thu, 16 Mar 2023 08:59:36 -0700 (PDT) X-Google-Smtp-Source: AK7set/oJ0/tB2fkaNC/1bDe+vQ8WOfrmWUjpL+4T6aNgyckRrsJsKKBVBexygqFrj4T03vfD1dv4g== X-Received: by 2002:a05:622a:1486:b0:3b8:6cb0:8d28 with SMTP id t6-20020a05622a148600b003b86cb08d28mr7278238qtx.6.1678982376354; Thu, 16 Mar 2023 08:59:36 -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 d4-20020a05622a100400b003b9bc00c2f1sm5994995qte.94.2023.03.16.08.59.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Mar 2023 08:59:35 -0700 (PDT) Message-ID: <5bba3382-dee7-2bab-d016-8d48b17a1580@redhat.com> Date: Thu, 16 Mar 2023 11:59:34 -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> <67e8023b-df78-f522-a643-c14b69719600@idea> From: Jason Merrill In-Reply-To: <67e8023b-df78-f522-a643-c14b69719600@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=-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 11:48, Patrick Palka wrote: > On Thu, 16 Mar 2023, Jason Merrill wrote: > >> 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? > > Looks like check_narrowing isn't called at all in this aggr init case. > The call from e.g. convert_like_internal isn't reached because the > conversion for the initializer element is ck_identity, and don't ever > set conversion::check_narrowing for ck_identity conversions I think. Ah, yes, that makes sense; an identity conversion can never be narrowing, so we don't care about the constant value. So not instantiating seems correct, and the patch is OK. > Yet for using 'type = decltype(int{f(0)});' (similar to the example in > [temp.inst]/8) we do call check_narrowing directly from > finish_compound_literal, despite the conversion effectively being an > identity conversion. Hmm, maybe check_narrowing should defer constant evaluation until after deciding that the target type is not a superset of the source type... >>> 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 >>> +} >> >> >