From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id DADCE3857C48 for ; Mon, 7 Sep 2020 22:23:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DADCE3857C48 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-436-KyECRKPzO2KwYSNNWRkyKg-1; Mon, 07 Sep 2020 18:23:04 -0400 X-MC-Unique: KyECRKPzO2KwYSNNWRkyKg-1 Received: by mail-qk1-f198.google.com with SMTP id a2so2947732qkg.19 for ; Mon, 07 Sep 2020 15:23:04 -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:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ur49RWJ6E+b99TSxsbtIAmzfP5NkdJ7ZT95Uw3Ut0pU=; b=iU8nDyQrEQZSdfjOSCj7kCBv+3/+8KL+TrV6SAnCDdO/PjNBY77JrzUyIJPdGe22cg SP9H6lsdzxBVfhv7JocYfJZiIkW2IiN7OAAXWRdvkBnwLXHK15yMyAz19RjrYNukzrlS u/QBy7Zhveea+o+MRBdz+4HAgeR31VAYV3Un6bXw1m+TFaE2MRW0EdOuZ0z5CyiMCDtb jB9rjVo2mCJswD00lxinLHfAgS2bNdJrRTNV9RglIBHuWCBr/XpxuYhTe0t0zkR2J3hq 3/XTEgzMGqMjLTIkSWSnD/HpyBesWRW28wsfdgh/8CJnBeSmAuJTo00XgrDEbUV2r38Q C77A== X-Gm-Message-State: AOAM5334mb//JdzL4CLnF/zndsJgzWG36pPHIoOiyxSjLBeUaV4/FHTO c5VVGgD3gWdf1XDZV0dYf2zGvV9rsgZRWiZImAu2mSVnBKP+EB8Ue9ScvyHARB/OYfM0p9yRqGV C2sCSrsOzKfY8VvOAFQ== X-Received: by 2002:a37:a1cb:: with SMTP id k194mr20724699qke.354.1599517383391; Mon, 07 Sep 2020 15:23:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwiHdIkYhdSMV6AVdTp0fhhB0rQOceMWqZrNiDAUqX+x+ZR9XSqId+fpUjHoZtrAzANmfg9rQ== X-Received: by 2002:a37:a1cb:: with SMTP id k194mr20724684qke.354.1599517383065; Mon, 07 Sep 2020 15:23:03 -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 u17sm12616795qtq.20.2020.09.07.15.23.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Sep 2020 15:23:02 -0700 (PDT) Subject: Re: [PATCH] c++: Fix ICE in reshape_init with init-list [PR95164] To: Marek Polacek , GCC Patches References: <20200904213922.2543048-1-polacek@redhat.com> From: Jason Merrill Message-ID: <966f88ec-b6d8-0803-ef1a-fbff81583cc9@redhat.com> Date: Mon, 7 Sep 2020 18:23:01 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200904213922.2543048-1-polacek@redhat.com> X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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, 07 Sep 2020 22:23:08 -0000 On 9/4/20 5:39 PM, Marek Polacek wrote: > This patch fixes a long-standing bug in reshape_init_r. Since r209314 > we implement DR 1467 which handles list-initialization with a single > initializer of the same type as the target. In this test this causes > a crash in reshape_init_r when we're processing a constructor that has > undergone the DR 1467 transformation. > > Take e.g. the > > foo({{1, {H{k}}}}); > > line in the attached test. {H{k}} initializes the field b of H in I. > H{k} is a functional cast, so has TREE_HAS_CONSTRUCTOR set, so is > COMPOUND_LITERAL_P. We perform the DR 1467 transformation and turn > {H{k}} into H{k}. Then we attempt to reshape H{k} again and since > first_initializer_p is null and it's COMPOUND_LITERAL_P, we go here: > > else if (COMPOUND_LITERAL_P (stripped_init)) > gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init)); It looks to me like the bug is here: > /* [dcl.init.aggr] > > All implicit type conversions (clause _conv_) are considered when > initializing the aggregate member with an initializer from an > initializer-list. If the initializer can initialize a member, > the member is initialized. Otherwise, if the member is itself a > non-empty subaggregate, brace elision is assumed and the > initializer is considered for the initialization of the first > member of the subaggregate. */ > if (TREE_CODE (init) != CONSTRUCTOR > /* But don't try this for the first initializer, since that would be > looking through the outermost braces; A a2 = { a1 }; is not a > valid aggregate initialization. */ > && !first_initializer_p > && (same_type_ignoring_top_level_qualifiers_p (type, TREE_TYPE (init)) > || can_convert_arg (type, TREE_TYPE (init), init, LOOKUP_NORMAL, > complain))) > { > d->cur++; > return init; > } We ought to handle H{k} here, treat it as the initializer for the member, and not get as far as the code you quote above. Jason