From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59811 invoked by alias); 19 Feb 2020 18:30:35 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 59643 invoked by uid 89); 19 Feb 2020 18:30:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Feb 2020 18:30:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582137015; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EdT6G9qhfHAXfAFyzWgxqC4zJ72pyZWvNFtC+O+AIn4=; b=Ac9p20BpzUFsJiOZB83irL1EUOgpl7t8jWuSuAbdokjzKbAEa9rXYV0dzQPuH6dtxftSSA OKd9MthFZRIErOkon+OzBqTOp0+gcGBrK8EcQd86W3AjYoj3BgIvri/gIRAkCGUAXObq4v A4J5mUC8uTgXpiaNUc8fXO6lHXTN4zw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-82-x0T49oUEMeqTPJd4ey9JFg-1; Wed, 19 Feb 2020 13:30:13 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A3B00800D5F for ; Wed, 19 Feb 2020 18:30:12 +0000 (UTC) Received: from redhat.com (ovpn-120-157.rdu2.redhat.com [10.10.120.157]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 23A4D60FC2; Wed, 19 Feb 2020 18:30:11 +0000 (UTC) Date: Wed, 19 Feb 2020 18:30:00 -0000 From: Marek Polacek To: Jason Merrill Cc: GCC Patches Subject: Re: [PATCH] c++: Fix ICE with ill-formed array list-initialization [PR93712] Message-ID: <20200219183009.GB3559@redhat.com> References: <20200213195600.495394-1-polacek@redhat.com> <2143009f-35d4-456d-78ac-46e748a55538@redhat.com> MIME-Version: 1.0 In-Reply-To: <2143009f-35d4-456d-78ac-46e748a55538@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SW-Source: 2020-02/txt/msg01118.txt.bz2 On Fri, Feb 14, 2020 at 09:12:58AM +0100, Jason Merrill wrote: > On 2/13/20 8:56 PM, Marek Polacek wrote: > > My P0388R4 patch changed build_array_conv to create an identity > > conversion at the start of the conversion chain. >=20 > Hmm, an identity conversion of {} suggests that it has a type, which it > doesn't in the language. I'm not strongly against it, but what was the > reason for this change? There are two reasons: 1) without it we couldn't get to the original expression at the start of the conversion chain (saved in .u.expr), this is needed in compare_ics: 10660 tree n1 =3D nelts_initialized_by_list_init (t1); 10661 tree n2 =3D nelts_initialized_by_list_init (t2); and nelts_initialized_by_list_init uses conv_get_original_expr for arrays that have no dimensions. 2) struct conversion says /* An implicit conversion sequence, in the sense of [over.best.ics]. The first conversion to be performed is at the end of the chain. That conversion is always a cr_identity conversion. */ and we were breaking that promise. > > That was a sound change but now we crash in convert_like_real > >=20 > > 7457 case ck_identity: > > 7458 if (BRACE_ENCLOSED_INITIALIZER_P (expr)) > > 7459 { > > 7460 int nelts =3D CONSTRUCTOR_NELTS (expr); > > 7461 if (nelts =3D=3D 0) > > 7462 expr =3D build_value_init (totype, complain); > > 7463 else if (nelts =3D=3D 1) > > 7464 expr =3D CONSTRUCTOR_ELT (expr, 0)->value; > > 7465 else > > 7466 gcc_unreachable (); // HERE > > 7467 } >=20 > Right, this is assuming that any other {} will either be ill-formed or > handled by ck_aggr or ck_list. How are we getting here without going > through one of those? So here we have a ck_aggr which is bad_p, so in convert_like_real we go to = the 7285 if (convs->bad_p block at the beginning, which will look at the next conversion: 7319 for (; t ; t =3D next_conversion (t)) that conversion is a ck_identity which is not bad_p, so we call 7343 else if (t->kind =3D=3D ck_user || !t->bad_p) 7344 { 7345 expr =3D convert_like_real (t, expr, fn, argnum, 7346 /*issue_conversion_warnings= =3D*/false, 7347 /*c_cast_p=3D*/false, 7348 complain); and crash there. Marek