From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17466 invoked by alias); 28 Dec 2018 19:40:04 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 17456 invoked by uid 89); 28 Dec 2018 19:40:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=aside, pero, board, engineer X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Dec 2018 19:40:02 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7197583F51; Fri, 28 Dec 2018 19:40:01 +0000 (UTC) Received: from free.home (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 59E1460C45; Fri, 28 Dec 2018 19:40:00 +0000 (UTC) Received: from libre (free-to-gw.home [172.31.160.161]) by free.home (8.15.2/8.15.2) with ESMTP id wBSJdOcb458567; Fri, 28 Dec 2018 17:39:27 -0200 From: Alexandre Oliva To: Jason Merrill Cc: Christophe Lyon , gcc-patches List Subject: Re: [C++ Patch] [PR c++/88146] do not crash synthesizing inherited ctor(...) References: <81ac6c22-8907-a166-b8df-80e06d2850da@redhat.com> <12883fc9-4e44-e16d-fdc6-9a90c21bf01c@redhat.com> Date: Fri, 28 Dec 2018 22:53:00 -0000 In-Reply-To: (Jason Merrill's message of "Thu, 20 Dec 2018 11:09:18 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-12/txt/msg01742.txt.bz2 On Dec 20, 2018, Jason Merrill wrote: > I think the bug is in calling instantiate_constexpr_fns in this case. > I think that should only happen when ctx->manifestly_const_eval. FTR, changing that breaks cpp2a/constexpr-init1.C (P0859), unfortunately. I don't see why the operand of decltype or of int{} would be manifestly const eval. Plus, I don't quite follow why the two cases covered in the constexpr-init1.C testcase have different consequences, constexpr-wise, even after rereading the verbiage about it in the standard development tree a few times; I guess I still need to fill in other gaps to in my knowledge to try and make sense of it. diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c index cea414d33def..88bee7aa1fed 100644 --- a/gcc/cp/constexpr.c +++ b/gcc/cp/constexpr.c @@ -5076,7 +5076,8 @@ cxx_eval_outermost_constant_expr (tree t, bool allow_= non_constant, r =3D TARGET_EXPR_INITIAL (r); } =20 - instantiate_constexpr_fns (r); + if (ctx.manifestly_const_eval) + instantiate_constexpr_fns (r); r =3D cxx_eval_constant_expression (&ctx, r, false, &non_constant_p, &overflow_p); =20 But, really, should varying but user-invisible cdtor return types really ever play a role in determining whether a program is well-formed, like they do ATM? I mean, is my suggested change wrong or undesirable for some reason I can't grasp, aside from its incorrect implementation, using operand0 of CALL_EXPR instead of operand0 of the ADDR_EXPR that will be operand1 of CALL_EXPR if it's not NULL? diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c index f758f2d9bc8f..9b3b4d039a16 100644 --- a/gcc/cp/cvt.c +++ b/gcc/cp/cvt.c @@ -1118,7 +1118,8 @@ convert_to_void (tree expr, impl_conv_void implicit, = tsubst_flags_t complain) error_at (loc, "pseudo-destructor is not called"); return error_mark_node; } - if (VOID_TYPE_P (TREE_TYPE (expr))) + if (VOID_TYPE_P (TREE_TYPE (expr)) + && TREE_CODE (expr) !=3D CALL_EXPR) return expr; switch (TREE_CODE (expr)) { @@ -1175,6 +1176,26 @@ convert_to_void (tree expr, impl_conv_void implicit,= tsubst_flags_t complain) break; =20 case CALL_EXPR: /* We have a special meaning for volatile void fn().= */ + /* cdtors may return this or void, depending on + targetm.cxx.cdtor_returns_this, but this shouldn't affect our + decisions here: nodiscard cdtors are nonsensical, and we + don't want to call maybe_warn_nodiscard because it may + trigger constexpr or template instantiation in a way that + changes their instantiaton nesting. This changes the way + contexts are printed in diagnostics, with bad consequences + for the testsuite, but there may be other undesirable + consequences of visiting referenced ctors too soon. */ + if (TREE_OPERAND (expr, 1) + && TREE_CODE (TREE_OPERAND (expr, 1)) =3D=3D ADDR_EXPR + && DECL_P (TREE_OPERAND (TREE_OPERAND (expr, 1), 0)) + && IDENTIFIER_CDTOR_P (DECL_NAME (TREE_OPERAND (TREE_OPERAND (expr, 1),= 0)))) + return expr; + /* FIXME: Move this test before the one above, after a round of + testing as it is, to get coverage of the behavior we'd get on + ARM. */ + else if (VOID_TYPE_P (TREE_TYPE (expr))) + return expr; + maybe_warn_nodiscard (expr, implicit); break; =20 --=20 Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain Engineer Free Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jam=C3=A1s-GNUChe