From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102170 invoked by alias); 25 Jan 2018 21:16:56 -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 102156 invoked by uid 89); 25 Jan 2018 21:16:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_SHORT,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= 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; Thu, 25 Jan 2018 21:16:54 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1F97E30033F for ; Thu, 25 Jan 2018 21:16:53 +0000 (UTC) Received: from redhat.com (ovpn-204-27.brq.redhat.com [10.40.204.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 63BE0605D8; Thu, 25 Jan 2018 21:16:52 +0000 (UTC) Date: Thu, 25 Jan 2018 21:58:00 -0000 From: Marek Polacek To: GCC Patches , Jason Merrill Subject: C++ PATCH to fix rejects-valid with constexpr ctor in C++17 (PR c++/83692) Message-ID: <20180125211639.GA2620@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-SW-Source: 2018-01/txt/msg02135.txt.bz2 This is a similar problem to 83116: we'd cached a constexpr call, but after a store the result had become invalid, yet we used the wrong result again when encountering the same call later. This resulted in evaluating a THROW_EXPR which doesn't work. Details in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692#c5 The fix for 83116 didn't work here, because when evaluating the body of the ctor via store_init_value -> cxx_constant_value we are in STRICT, so we do cache. It seems that we may no longer rely on the constexpr call table when we do cxx_eval_store_expression, because that just rewrites *valp, i.e. the value of an object. Might be too big a hammer again, but I couldn't think of how I could guard the caching of a constexpr call. This doesn't manifest in C++14 because build_special_member_call in C++17 is more aggressive with copy elisions (as required by P0135 which changed how we view prvalues). In C++14 build_special_member_call produces a CALL_EXPR, so expand_default_init calls maybe_constant_init, for which STRICT is false, so we avoid caching as per 83116. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2018-01-25 Marek Polacek PR c++/83692 * constexpr.c (cxx_eval_store_expression): Clear constexpr_call_table. * g++.dg/cpp1y/constexpr-83692.C: New test. diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c index 4d2ee4a28fc..0202d22f320 100644 --- gcc/cp/constexpr.c +++ gcc/cp/constexpr.c @@ -3663,6 +3663,10 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, tree t, else *valp = init; + /* We've rewritten a value of a temporary in this constexpr + context which might invalide a cached call. */ + constexpr_call_table = NULL; + /* Update TREE_CONSTANT and TREE_SIDE_EFFECTS on enclosing CONSTRUCTORs, if any. */ tree elt; diff --git gcc/testsuite/g++.dg/cpp1y/constexpr-83692.C gcc/testsuite/g++.dg/cpp1y/constexpr-83692.C index e69de29bb2d..292ba7c22e9 100644 --- gcc/testsuite/g++.dg/cpp1y/constexpr-83692.C +++ gcc/testsuite/g++.dg/cpp1y/constexpr-83692.C @@ -0,0 +1,21 @@ +// PR c++/83692 +// { dg-do compile { target c++14 } } + +struct integer { + constexpr int value() const { return m_value; } + int m_value; +}; + +struct outer { + integer m_x{0}; + constexpr outer() + { + if (m_x.value() != 0) + throw 0; + m_x.m_value = integer{1}.value(); + if (m_x.value() != 1) + throw 0; + } +}; + +constexpr outer o{}; Marek