From patchwork Tue Mar 20 13:32:05 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Polacek X-Patchwork-Id: 888218 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-475020-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="LsW9pahJ"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 405DPn4VMQz9s0y for ; Wed, 21 Mar 2018 00:32:29 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; q=dns; s= default; b=eXuKve/9BdQPsxZX+QK907WCGJ2mXRy7Ud8TqkEC8VVp3/W1SrXgt qxi35sAS+l9w6L/pvIEsPzlcdFphfnP5ldsoNSo25uFG4BpmrOyD9K60+0kyDvdI QFAERAP+echXfpJV6HO2mPRRzapjUniiqZ24qgv/dsT/IYrouKFJw0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; s= default; bh=5I+EnzAk9RwrMS7fMPn/Dag6JHk=; b=LsW9pahJElk7VR7OFsHm o8lA5SQl1OH8a4unoT0llnfNOC6H4RG6jZA6eQW0zxhpL99u9dnqXzqt4kE2NMmu p/FW1Ao3JDZn7zSQNZHDCl826A2H6+O0j+A6cjSmVq/6IZV29/30bvZfZ1IKsnnL WXrW1h3evv5YCFEFFsX9e8U= Received: (qmail 92613 invoked by alias); 20 Mar 2018 13:32:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 92586 invoked by uid 89); 20 Mar 2018 13:32:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No 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, 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; Tue, 20 Mar 2018 13:32:21 +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 0191B81247 for ; Tue, 20 Mar 2018 13:32:20 +0000 (UTC) Received: from redhat.com (ovpn-204-120.brq.redhat.com [10.40.204.120]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0228A7A412; Tue, 20 Mar 2018 13:32:16 +0000 (UTC) Date: Tue, 20 Mar 2018 14:32:05 +0100 From: Marek Polacek To: GCC Patches , Jason Merrill Subject: C++ PATCH for c++/84978, ICE with NRVO Message-ID: <20180320133205.GE3522@redhat.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) We started crashing on this test with r258592 which added cp_get_callee_fndecl in in cp_genericize_r. This ICE apparently depends on whether we perform NRVO or not. If the size of S is <=16B we pass it in registers and it compiles fine. But if the size of S is >16B, then we pass in memory, and we NRV-optimize. That means that s.fn (); is turned by finalize_nrv into .fn (); Then the newly added call to cp_get_callee_fndecl calls maybe_constant_init, which ends up evaluating , but it's not in the hash map, so we crash here: 4111 /* We ask for an rvalue for the RESULT_DECL when indirecting 4112 through an invisible reference, or in named return value 4113 optimization. */ 4114 return (*ctx->values->get (t)); I thought we could be more careful and not blindly dereference the result of get(). After all, it's not a problem here if the cannot be evaluated to a constant. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2018-03-20 Marek Polacek PR c++/84978 * constexpr.c (cxx_eval_constant_expression): Handle the case when a RESULT_DECL isn't in the hash map. * g++.dg/opt/nrv19.C: New test. Marek diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c index 894bcd0bb3e..1f8ece89730 100644 --- gcc/cp/constexpr.c +++ gcc/cp/constexpr.c @@ -4111,7 +4111,15 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, tree t, /* We ask for an rvalue for the RESULT_DECL when indirecting through an invisible reference, or in named return value optimization. */ - return (*ctx->values->get (t)); + if (tree *p = ctx->values->get (t)) + return *p; + else + { + if (!ctx->quiet) + error ("%qE is not a constant expression", t); + *non_constant_p = true; + } + break; case VAR_DECL: if (DECL_HAS_VALUE_EXPR_P (t)) diff --git gcc/testsuite/g++.dg/opt/nrv19.C gcc/testsuite/g++.dg/opt/nrv19.C index e69de29bb2d..385593cc90c 100644 --- gcc/testsuite/g++.dg/opt/nrv19.C +++ gcc/testsuite/g++.dg/opt/nrv19.C @@ -0,0 +1,15 @@ +// PR c++/84978 +// { dg-do compile } + +struct S { + void (*fn)(); + int a[10]; +}; + +S +foo () +{ + S s; + s.fn (); + return s; +}