From patchwork Fri Nov 3 17:33:05 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Carlini X-Patchwork-Id: 834024 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-465899-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="e7y9b60d"; 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 3yT8Dy5ZLfz9sRm for ; Sat, 4 Nov 2017 04:33:21 +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:to:cc :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=xg/MVf7I5R8m4piJfgoLHbYCqWy38sf4qaPv7a6pX4pS+oGOBp 0dKrYBbWRBSZDn0rEFL/WHd4CKMmrG1T0nlmiGMJYsY87q+HPGQWL4yJW5DprAu4 d4GQpDksrPWdm2NZ8P7l9g24c1d+cubXXQeqID1iK+2Tc/ip9V6xO6UUQ= 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:to:cc :from:subject:message-id:date:mime-version:content-type; s= default; bh=QLkfgTEdYuaOi4fyv5sTUDR2eCo=; b=e7y9b60dPu0sprBvuOl6 6Ju3H4v/Hgj79jEDYW4CfmJ2P124v86a2HOnKMC9SfsU3XwmSKjRx8oaO+k1+/cr v2KeSGvOuGZ1h1fb+cw1U33n8Gp8BMDeSFn5W2T0YJWYQq9fk1FVU4Hbc2ljKPgF viOFMNLLHT3ScqnlS0jUCrI= Received: (qmail 115685 invoked by alias); 3 Nov 2017 17:33:13 -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 115675 invoked by uid 89); 3 Nov 2017 17:33:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-15.1 required=5.0 tests=BAYES_00, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=designated, Hx-languages-length:1625, gnus X-HELO: userp1040.oracle.com Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 03 Nov 2017 17:33:12 +0000 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA3HX92V028708 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 3 Nov 2017 17:33:09 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA3HX92o006108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 3 Nov 2017 17:33:09 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vA3HX8oo016326; Fri, 3 Nov 2017 17:33:08 GMT Received: from [192.168.1.4] (/87.17.208.57) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 Nov 2017 10:33:08 -0700 To: "gcc-patches@gcc.gnu.org" Cc: Jason Merrill From: Paolo Carlini Subject: [C++ Patch/RFC] PR 82593 ("Internal compiler error: in process_init_constructor_array, at cp/typeck2.c:1294") Message-ID: <63e16891-28c6-aa37-6f1a-1288a19e9cfe@oracle.com> Date: Fri, 3 Nov 2017 18:33:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 X-IsSubscribed: yes Hi, this ICE on valid (given GNU's designated initializers) is rather simple to analyze: for the testcase, the gcc_assert in process_init_constructor_array triggers because at that time INDEX1 is still a CONST_DECL, not an INTEGER_CST. As regards fixing the problem, I immediately noticed earlier today that fold_non_dependent_expr is definitely able to fold the CONST_DECL to the expected zero INTEGER_CST - and that also passes testing - but I'm not sure that in the big picture folding at that time is correct. Thanks in advance for any feedback! Paolo. ////////////////// Index: cp/typeck2.c =================================================================== --- cp/typeck2.c (revision 254365) +++ cp/typeck2.c (working copy) @@ -1291,6 +1291,7 @@ process_init_constructor_array (tree type, tree in { if (ce->index) { + ce->index = fold_non_dependent_expr (ce->index); gcc_assert (TREE_CODE (ce->index) == INTEGER_CST); if (compare_tree_int (ce->index, i) != 0) { Index: testsuite/g++.dg/cpp0x/desig2.C =================================================================== --- testsuite/g++.dg/cpp0x/desig2.C (nonexistent) +++ testsuite/g++.dg/cpp0x/desig2.C (working copy) @@ -0,0 +1,23 @@ +// PR c++/82593 +// { dg-do compile { target c++11 } } +// { dg-options "" } + +enum { + INDEX1 = 0, + INDEX2 +}; + +class SomeClass { +public: + SomeClass(); +private: + struct { int field; } member[2]; +}; + +SomeClass::SomeClass() + : member({ + [INDEX1] = { .field = 0 }, + [INDEX2] = { .field = 1 } + }) +{ +}