From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 39442396E83C for ; Thu, 2 Jun 2022 14:03:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 39442396E83C Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-62-Ia2RAEW9NkalAJLgMuZqGQ-1; Thu, 02 Jun 2022 10:03:20 -0400 X-MC-Unique: Ia2RAEW9NkalAJLgMuZqGQ-1 Received: by mail-qk1-f198.google.com with SMTP id o18-20020a05620a2a1200b006a0cc3d8463so3757275qkp.4 for ; Thu, 02 Jun 2022 07:03:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=wpdtPaTY0SvDQfI7X69VcqtyGlwu/hT5O3nYvqDJRh4=; b=zALdqFC2KsotVLb1LnrwAKP6FSzbXRcINg9k3cF5wf8C6SrAoPVVZl3r2Dmg0SwacJ ht6n30TQosUiwoEuEvbtA982qtoR/SNtCRFFA2VBSDowL56VDWc97WcWzhrt5gokUMAx N0dJSnrsk4M82u8AbOU4zvRwQgYrBqJInTt0dQez60apxEfL6m0WRCwEaTTXwmL6YB8E il+L7CQPVaih5Xdb6klKULli61u1wRuLDP6CAA4Koqy5EJe/SXaqXsxsKwPyvfnGouGm KqjbgS6S48HTHMy/5Fu8cvEl0a1dMkigjGZdeGccTQvaTjBMdTewsR00RdK0hI5dyVb5 O1jw== X-Gm-Message-State: AOAM5330vcSWf6N5tKPXzeoaqh4RUXNDZysH1FniXVax3i3BJ7mKb/jr u+1EKPOEGkLdx2bk44OPtm8blDh5UUTB0eaOwQhDD7JI0PbsJkDzfvzGbxMJ3px19ixNyUu54zd KlMeeIeqL30agYKwHIQ== X-Received: by 2002:a05:622a:5d4:b0:304:b50c:8e9e with SMTP id d20-20020a05622a05d400b00304b50c8e9emr3645090qtb.683.1654178600005; Thu, 02 Jun 2022 07:03:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJysuaGuSS9iE3mo95hIBg56Q8FGzd8pDkoOid+eCZrcDlF9VR1JNOa28r5PByO/1bfLdVIDjA== X-Received: by 2002:a05:622a:5d4:b0:304:b50c:8e9e with SMTP id d20-20020a05622a05d400b00304b50c8e9emr3645056qtb.683.1654178599730; Thu, 02 Jun 2022 07:03:19 -0700 (PDT) Received: from redhat.com ([2601:184:4780:4310::9979]) by smtp.gmail.com with ESMTPSA id t194-20020a3746cb000000b006a371ba1fa5sm3208784qka.32.2022.06.02.07.03.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jun 2022 07:03:19 -0700 (PDT) Date: Thu, 2 Jun 2022 10:03:17 -0400 From: Marek Polacek To: Patrick Palka Cc: Jason Merrill , GCC Patches Subject: Re: [PATCH] c++: ICE with template NEW_EXPR [PR105803] Message-ID: References: <20220601224536.1553412-1-polacek@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.2.1 (2022-02-19) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Thu, 02 Jun 2022 14:03:27 -0000 On Thu, Jun 02, 2022 at 08:42:36AM -0400, Patrick Palka wrote: > On Wed, 1 Jun 2022, Marek Polacek via Gcc-patches wrote: > > > Here we ICE because value_dependent_expression_p gets a NEW_EXPR > > whose operand is a type, and we go to the default case which just > > calls v_d_e_p on each operand of the NEW_EXPR. Since one of them > > is a type, we crash on the new assert in t_d_e_p. > > Looks like NEW_EXPR is considered to be not potentially constant > according to potential_constant_expression. I thought we shouldn't > be calling value_dependent_expression_p on such exprs? You're correct. This is non-obvious: instantiation_dependent_expression_p calls p_c_e before v_d_e_p, but the expression is CAST_EXPR<[NEW_EXPR]>, where the [] denotes a TREE_LIST, created in cp_parser_functional_cast. This TREE_LIST has no type. So p_c_e_1/CAST_EXPR goes to 9183 /* If this is a dependent type, it could end up being a class 9184 with conversions. */ 9185 if (type == NULL_TREE || WILDCARD_TYPE_P (type)) 9186 return true; and returns true. So we call v_d_e_p, which looks at the CAST_EXPR's op and sees a TREE_LIST, so it calls any_value_dependent_elements_p, and we end up with a NEW_EXPR. An alternative/more proper fix would be to fix p_c_e_1/CAST_EXPR. Maybe by calling any_type_dependent_elements_p (which currently has no uses). Thoughts? > > --- /dev/null > > +++ b/gcc/testsuite/g++.dg/template/new13.C > > @@ -0,0 +1,11 @@ > > +// PR c++/105803 > > +// { dg-do compile } > > +// { dg-additional-options "-fchecking=2" } > > + > > +namespace std { > > +template class shared_ptr; > > +} > > +struct S {}; > > +template void build_matrices() { > > + std::shared_ptr(new S); > > +} > > I think this testcase might be IFNDR since shared_ptr is incomplete > at the point of its non-dependent use. Ah, overreduced. I've made shared_ptr complete. Marek