From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17104 invoked by alias); 29 Dec 2018 02:34:33 -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 17095 invoked by uid 89); 29 Dec 2018 02:34:33 -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=transparent, deeper 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; Sat, 29 Dec 2018 02:34:31 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 00FCB85541; Sat, 29 Dec 2018 02:34:30 +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 A59F85D737; Sat, 29 Dec 2018 02:34:29 +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 wBT2YJJ8477540; Sat, 29 Dec 2018 00:34:20 -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: Sat, 29 Dec 2018 10:28:00 -0000 In-Reply-To: (Alexandre Oliva's message of "Fri, 28 Dec 2018 17:39:22 -0200") 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/msg01753.txt.bz2 On Dec 28, 2018, Alexandre Oliva wrote: > diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c And here's a cleaned-up patch based on my initial approach. [PR88146] avoid diagnostics diffs if cdtor_returns_this Diagnostics for testsuite/g++.dg/cpp0x/inh-ctor32.C varied across platforms. Specifically, on ARM, the diagnostics within the subtest derived_ctor::inherited_derived_ctor::constexpr_noninherited_ctor did not match those displayed on other platforms, and the test failed. The difference seemed to have to do with locations assigned to ctors, but it was more subtle: on ARM, the instantiation of bor's template ctor was nested within the instantiation of bar's template ctor inherited from bor. The reason turned out to be related with the internal return type of ctors: arm_cxx_cdtor_returns_this is enabled for because of AAPCS, while cxx.cdtor_returns_this is disabled on most other platforms. While convert_to_void returns early with a VOID expr, the non-VOID return type of the base ctor CALL_EXPR causes convert_to_void to inspect the called decl for nodiscard attributes: maybe_warn_nodiscard -> cp_get_fndecl_from_callee -> maybe_constant_init -> cxx_eval_outermost_constant_expr -> instantiate_constexpr_fns -> nested instantiation. The internal return type assigned to a cdtor should not affect instantiation (constexpr or template) decisions, IMHO. We know it affects diagnostics, but I have a hunch this might bring deeper issues with it, so I've arranged for the CALL_EXPR handler in convert_to_void to disregard cdtors, regardless of the ABI. Regstrapped on x86_64- and i686-linux-gnu. Ok to install? for gcc/cp/ChangeLog PR c++/88146 * cvt.c (convert_to_void): Handle all cdtor calls as if returning void. --- gcc/cp/cvt.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c index f758f2d9bc8f..092c81434e33 100644 --- a/gcc/cp/cvt.c +++ b/gcc/cp/cvt.c @@ -1175,6 +1175,18 @@ 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: neither nodiscard warnings (nodiscard cdtors + are nonsensical), nor should any constexpr or template + instantiations be affected by an ABI property that is, or at + least ought to be transparent to the language. */ + 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; + 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