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 8A67B38418A2 for ; Thu, 2 Jun 2022 12:42:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8A67B38418A2 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-532-4IA9fc3VMdGvLb8nMzWzPQ-1; Thu, 02 Jun 2022 08:42:38 -0400 X-MC-Unique: 4IA9fc3VMdGvLb8nMzWzPQ-1 Received: by mail-qt1-f197.google.com with SMTP id t14-20020a05622a01ce00b002ff91ea4445so3593598qtw.2 for ; Thu, 02 Jun 2022 05:42:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=9sgJoQRz1zUBFqsNliU4RHFJyQOXLOcQWBl+dlJ2VDk=; b=iIgcRCN957G5SGuE3F/n3h8AfPg05UhANt3DVJ/Zz9Pe0T5o9JhZndzjyjgnABfThI WOKHo3xjABMpZj/zkmsYPaFuFlPj4t5OdBNSuwKKByuabAasWeJgeoGvEgySV5LjDAtc 5q6jlCdZ5HeLm+SG6CGhcIuwHceoUy4DW1Jalq/mNsU3sBkOIk/pd5g5ZVStrnERS//t 11kTPBFojl6dbSEC8ZVCfY5u4wdJyIhPGnhYpi4M7HogupGVeCIkD/UJq/RQuQyirZhP ELnjGV0oGIavOZsQd9RCyI5kEALJs+aZxc94fIxfFmKviKaHMVhJhgSKhgBry0N1eANB AkJA== X-Gm-Message-State: AOAM530BfOYabuEIh6yIV7gwPH+g9ka1E1Z0mQFBcIotXUndUjNyUqU7 lJDsaiV0ISP21MzHcZItICujHOMOzlLVw1N0Vz+oRkNlJusPgJWqtie4nm9U0QE2/fqZGlW74ZU DIfxRQSJnkOfceDmaew== X-Received: by 2002:a37:8ac6:0:b0:6a6:1073:2b37 with SMTP id m189-20020a378ac6000000b006a610732b37mr2902913qkd.115.1654173757626; Thu, 02 Jun 2022 05:42:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxZ87tKgs+DL4fTXLU4rJRq36aJTMUVs5epknk/1SLqvin9GgzzOCgphe2fawztNLxsiCrHkw== X-Received: by 2002:a37:8ac6:0:b0:6a6:1073:2b37 with SMTP id m189-20020a378ac6000000b006a610732b37mr2902897qkd.115.1654173757378; Thu, 02 Jun 2022 05:42:37 -0700 (PDT) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id z11-20020ac8100b000000b002f90c73ad8csm2872425qti.7.2022.06.02.05.42.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jun 2022 05:42:37 -0700 (PDT) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Thu, 2 Jun 2022 08:42:36 -0400 (EDT) To: Marek Polacek cc: Jason Merrill , GCC Patches Subject: Re: [PATCH] c++: ICE with template NEW_EXPR [PR105803] In-Reply-To: <20220601224536.1553412-1-polacek@redhat.com> Message-ID: References: <20220601224536.1553412-1-polacek@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-14.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, 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 12:42:41 -0000 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? > > t_d_e_p has code to handle {,VEC_}NEW_EXPR, which at this point > was already performed, so I think we can handle these two codes > specifically and skip the second operand, which is always going > to be a type. > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > PR c++/105803 > > gcc/cp/ChangeLog: > > * pt.cc (value_dependent_expression_p): Handle {,VEC_}NEW_EXPR > in the switch. > > gcc/testsuite/ChangeLog: > > * g++.dg/template/new13.C: New test. > --- > gcc/cp/pt.cc | 8 ++++++++ > gcc/testsuite/g++.dg/template/new13.C | 11 +++++++++++ > 2 files changed, 19 insertions(+) > create mode 100644 gcc/testsuite/g++.dg/template/new13.C > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc > index 6de8e496859..836861e1039 100644 > --- a/gcc/cp/pt.cc > +++ b/gcc/cp/pt.cc > @@ -27643,6 +27643,14 @@ value_dependent_expression_p (tree expression) > under instantiate_non_dependent_expr; it can't be constant. */ > return true; > > + case NEW_EXPR: > + case VEC_NEW_EXPR: > + /* The second operand is a type, which type_dependent_expression_p > + (and therefore value_dependent_expression_p) doesn't want to see. */ > + return (value_dependent_expression_p (TREE_OPERAND (expression, 0)) > + || value_dependent_expression_p (TREE_OPERAND (expression, 2)) > + || value_dependent_expression_p (TREE_OPERAND (expression, 3))); > + > default: > /* A constant expression is value-dependent if any subexpression is > value-dependent. */ > diff --git a/gcc/testsuite/g++.dg/template/new13.C b/gcc/testsuite/g++.dg/template/new13.C > new file mode 100644 > index 00000000000..3168374b26d > --- /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. > > base-commit: 2d546ff69455f7deadab65309de89d19380a8864 > -- > 2.36.1 > >