From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115398 invoked by alias); 25 Jan 2018 22:08:25 -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 115378 invoked by uid 89); 25 Jan 2018 22:08:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 22:08:23 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1702425B8E for ; Thu, 25 Jan 2018 22:08:22 +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 53E8A608F3; Thu, 25 Jan 2018 22:08:21 +0000 (UTC) Date: Thu, 25 Jan 2018 22:37:00 -0000 From: Marek Polacek To: GCC Patches , Jason Merrill Subject: Re: C++ PATCH to fix rejects-valid with constexpr ctor in C++17 (PR c++/83692) Message-ID: <20180125220818.GB2620@redhat.com> References: <20180125211639.GA2620@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180125211639.GA2620@redhat.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-SW-Source: 2018-01/txt/msg02138.txt.bz2 On Thu, Jan 25, 2018 at 10:16:39PM +0100, Marek Polacek wrote: > 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. ...so the testcase should actually test c++17. Consider that fixed. Marek