From patchwork Wed Sep 11 21:15:27 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Polacek X-Patchwork-Id: 1161288 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-508928-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="UENhxsKc"; 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 46TF7t6ZyRz9s00 for ; Thu, 12 Sep 2019 07:16:25 +1000 (AEST) 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=uLskhRxctSFyflzz3MsATZQxnlcDpjl/4PnMs2DwmuiSXz5pbKFnH /+AF1EmnRvRGDIFRUQgJP4r2HsEFFAGo8uJg8yLBwNvfU/Ry+hpsR9oshVFB17BM 8emhEhS3gG50PX53tGXkyC9Clqp2wTnJ1zL/PDOoXdnz5ry7bZ87ao= 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=A+bGkeFa6X1aHXbnWVTw3K41MvI=; b=UENhxsKce8nc+lg1T26e z1J2X/LSjuvBR+LTuT7pmINgWbyz4HJCktLtLW7UBVL3OhiYQl4/3zxxzNJS4Kov wjQcRxrRhuRB7FsyPGfHDjc19RpZ3PANbQAiMB7lAcHUcxnNL3CERxCQsJBVzklr tv2BiY6rR0XfxdrFLSQTOoE= Received: (qmail 31862 invoked by alias); 11 Sep 2019 21:16:15 -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 31648 invoked by uid 89); 11 Sep 2019 21:15:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-22.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=hands, sk:cp_buil, sk:maybe_c 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; Wed, 11 Sep 2019 21:15:38 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AD26782A3F4; Wed, 11 Sep 2019 21:15:30 +0000 (UTC) Received: from redhat.com (ovpn-121-27.rdu2.redhat.com [10.10.121.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 08B875D9E2; Wed, 11 Sep 2019 21:15:29 +0000 (UTC) Date: Wed, 11 Sep 2019 17:15:27 -0400 From: Marek Polacek To: GCC Patches , Jason Merrill , Nathan Sidwell Subject: C++ PATCH for c++/91740 - ICE with constexpr call and ?: in ARRAY_REF Message-ID: <20190911211527.GM14737@redhat.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) This ICEs since r267272 - more location wrapper nodes, but not because we can't cope with new location wrappers, but because that commit introduced a call to maybe_constant_value in cp_build_array_ref. In this testcase we call it with f (VIEW_CONVERT_EXPR("BAR")) ? 1 : 0 argument and that crashes in fold_convert because we end up trying to convert "BAR" of type const char[4] to const char * when evaluating the call. At this point, decay_conversion hasn't turned the argument into (const char *) "BAR" yet. The ICE doesn't occur without :?, because then the call will be wrapped in NON_DEPENDENT_EXPR and constexpr throws its hands (I'm anthropomorphizing) up when it encounters such an expression. I noticed that build_non_dependent_expr doesn't wrap op0 of ?: in N_D_E. This is so since r70606 -- Nathan, is there a reason not to do it? Doing it fixes this problem. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2019-09-11 Marek Polacek PR c++/91740 - ICE with constexpr call and ?: in ARRAY_REF. * pt.c (build_non_dependent_expr): Call build_non_dependent_expr for the first operand. * g++.dg/cpp1y/var-templ63.C: New test. diff --git gcc/cp/pt.c gcc/cp/pt.c index c5915a5ecd0..775389d8245 100644 --- gcc/cp/pt.c +++ gcc/cp/pt.c @@ -26709,7 +26709,7 @@ build_non_dependent_expr (tree expr) if (TREE_CODE (expr) == COND_EXPR) return build3 (COND_EXPR, TREE_TYPE (expr), - TREE_OPERAND (expr, 0), + build_non_dependent_expr (TREE_OPERAND (expr, 0)), (TREE_OPERAND (expr, 1) ? build_non_dependent_expr (TREE_OPERAND (expr, 1)) : build_non_dependent_expr (TREE_OPERAND (expr, 0))), diff --git gcc/testsuite/g++.dg/cpp1y/var-templ63.C gcc/testsuite/g++.dg/cpp1y/var-templ63.C new file mode 100644 index 00000000000..a65f53b2963 --- /dev/null +++ gcc/testsuite/g++.dg/cpp1y/var-templ63.C @@ -0,0 +1,5 @@ +// PR c++/91740 - ICE with constexpr call and ?: in ARRAY_REF. +// { dg-do compile { target c++14 } } + +constexpr bool f(const char*) { return true; } +template const char c = "FOO"[f("BAR") ? 1 : 0];