From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 81AF33945057 for ; Mon, 6 Apr 2020 14:47:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 81AF33945057 Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-60-F6OCT2eMOm6L31DanWc0aw-1; Mon, 06 Apr 2020 10:47:53 -0400 X-MC-Unique: F6OCT2eMOm6L31DanWc0aw-1 Received: by mail-qv1-f72.google.com with SMTP id e9so5784432qvr.9 for ; Mon, 06 Apr 2020 07:47:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=HI8JUOllkRJRoeaW/R4XDOegggA4BTwI4OgalEX1qYc=; b=OT4aQ8b+kqBG4vgAUvAfu8NJnkWoj3hi+UFUS57NgxhPb8SoIzfBkhmjavdGlCDZt7 K7Qd501W4FhzIp3PPa/v8qOrPgHrj0JUQCS2iuqDETj6zTlGVqwA/2nqaym39cQAi+kL ePG5eHZ0Ol+eR+g+wYI9G54Z3Krqiev4rICN0lInqP5fYEcNTvfzU/l5MU21hC5EjU5U LXF2U2O7SvKQ3OW/yx6Zjgjd9fFByBnjSE5m0BgzIgTV/nm49KyKPaphIFVhn86SOC0u qNd/aMgjsJtrFda6z0+tIx8YyKUC7avQz1HsxPbrBVA1ZWj3KtVHHE89wN8ds1efOVNx INRQ== X-Gm-Message-State: AGi0PuaMk0H0yYxKG27LRlR1nWaIdPlaLuQdQkyFWsRM9rdgPKT/mSOz TNc8DgVkTQP4HaCl8XAlwTT8ZWSofc+0gFWqsTVITweMsULZXbCUbcR71HKI6aK+f1uP4RuzQb7 oCl3enw2L7ICxdnf5gA== X-Received: by 2002:aed:3221:: with SMTP id y30mr20801465qtd.199.1586184472399; Mon, 06 Apr 2020 07:47:52 -0700 (PDT) X-Google-Smtp-Source: APiQypIPpOTirBFLDX8CRN3FWf54QrAWmmosXyBIMHItwmNLV9osxLNuSuQgPEyo42tOXiXPXbt5Jg== X-Received: by 2002:aed:3221:: with SMTP id y30mr20801437qtd.199.1586184471967; Mon, 06 Apr 2020 07:47:51 -0700 (PDT) Received: from [192.168.1.148] (209-6-216-142.s141.c3-0.smr-cbr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.216.142]) by smtp.gmail.com with ESMTPSA id x24sm2551091qth.80.2020.04.06.07.47.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Apr 2020 07:47:50 -0700 (PDT) Subject: Re: [PATCH v2] c++: Fix crash in gimplifier with paren init of aggregates [PR94155] To: Marek Polacek Cc: GCC Patches References: <20200330202823.428754-1-polacek@redhat.com> <20200404010813.GV2929@redhat.com> <79f201f2-3932-b10c-7f78-afda837c93e4@redhat.com> <20200404175638.GA633012@redhat.com> From: Jason Merrill Message-ID: <6d6371fa-429a-e061-337c-16235e1a94af@redhat.com> Date: Mon, 6 Apr 2020 10:47:49 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <20200404175638.GA633012@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="------------1357B35261DF61F2626AD935" X-Spam-Status: No, score=-30.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 14:47:57 -0000 This is a multi-part message in MIME format. --------------1357B35261DF61F2626AD935 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/4/20 1:56 PM, Marek Polacek wrote: > On Fri, Apr 03, 2020 at 10:39:49PM -0400, Jason Merrill via Gcc-patches wrote: >> On 4/3/20 9:08 PM, Marek Polacek wrote: >>> On Fri, Apr 03, 2020 at 03:01:37PM -0400, Jason Merrill via Gcc-patches wrote: >>>> On 3/30/20 4:28 PM, Marek Polacek wrote: >>>>> Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't >>>>> expect null indexes for a constructor: >>>>> >>>>> /* ??? Here's to hoping the front end fills in all of the indices, >>>>> so we don't have to figure out what's missing ourselves. */ >>>>> gcc_assert (purpose); >>>>> >>>>> The indexes weren't filled because we never called reshape_init: for >>>>> a constructor that represents parenthesized initialization of an >>>>> aggregate we don't allow brace elision or designated initializers. So >>>>> fill in the indexes manually, here we have an array, and we can simply >>>>> assign indexes starting from 0. >>>>> >>>>> Bootstrapped/regtested on x86_64-linux, ok for trunk? >>>> >>>> Shouldn't digest_init fill in the indexes? In >>>> process_init_constructor_array I see >>>> >>>> if (!ce->index) >>>> ce->index = size_int (i); >>> >>> Yes, that works too. Thus: >>> >>> Bootstrapped/regtested on x86_64-linux, ok for trunk? >>> >>> -- >8 -- >>> Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't >>> expect null indexes for a constructor: >>> >>> /* ??? Here's to hoping the front end fills in all of the indices, >>> so we don't have to figure out what's missing ourselves. */ >>> gcc_assert (purpose); >>> >>> The indexes weren't filled because we never called reshape_init: for >>> a constructor that represents parenthesized initialization of an >>> aggregate we don't allow brace elision or designated initializers. So >>> call digest_init to fill in the indexes. >>> >>> Bootstrapped/regtested on x86_64-linux, ok for trunk? >>> >>> PR c++/94155 - crash in gimplifier with paren init of aggregates. >>> * decl.c (check_initializer): Call digest_init. >>> >>> * g++.dg/cpp2a/paren-init22.C: New test. >>> --- >>> gcc/cp/decl.c | 5 +++++ >>> gcc/testsuite/g++.dg/cpp2a/paren-init22.C | 15 +++++++++++++++ >>> 2 files changed, 20 insertions(+) >>> create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init22.C >>> >>> diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c >>> index 69a238997b4..63e7bda09f5 100644 >>> --- a/gcc/cp/decl.c >>> +++ b/gcc/cp/decl.c >>> @@ -6754,6 +6754,11 @@ check_initializer (tree decl, tree init, int flags, vec **cleanups) >>> init = build_constructor_from_list (init_list_type_node, init); >>> CONSTRUCTOR_IS_DIRECT_INIT (init) = true; >>> CONSTRUCTOR_IS_PAREN_INIT (init) = true; >>> + /* The gimplifier expects that the front end fills in all of the >>> + indices. Normally, reshape_init_array fills these in, but we >>> + don't call reshape_init because that does nothing when it gets >>> + CONSTRUCTOR_IS_PAREN_INIT. */ >>> + init = digest_init (type, init, tf_warning_or_error); >> >> But why weren't we already calling digest_init in store_init_value? Was the >> CONSTRUCTOR making it all the way to gimplification still having >> init_list_type_node? > > It's because we set LOOKUP_ALREADY_DIGESTED a few lines below: > 6813 /* Don't call digest_init; it's unnecessary and will complain > 6814 about aggregate initialization of non-aggregate classes. */ > 6815 flags |= LOOKUP_ALREADY_DIGESTED; > and so store_init_value doesn't digest. Given the comment I'd be nervous about > not setting that flag here. OK, then why isn't it called by build_aggr_init? How is the CONSTRUCTOR getting a type without this being fixed up? ... Ah, because build_vec_init builds up a new CONSTRUCTOR and gives it a type without setting the indexes like process_init_constructor_array does: Jason --------------1357B35261DF61F2626AD935 Content-Type: text/x-patch; charset=UTF-8; name="vec-init.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vec-init.diff" diff --git a/gcc/cp/init.c b/gcc/cp/init.c index 27623cf4db1..ea95a3bc910 100644 --- a/gcc/cp/init.c +++ b/gcc/cp/init.c @@ -4438,6 +4438,8 @@ build_vec_init (tree base, tree maxindex, tree init, errors = true; if (try_const) { + if (!field) + field = size_int (idx); tree e = maybe_constant_init (one_init); if (reduced_constant_expression_p (e)) { --------------1357B35261DF61F2626AD935--