From patchwork Mon Oct 18 12:14:27 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 46339 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7E796385840D for ; Mon, 18 Oct 2021 12:15:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7E796385840D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1634559304; bh=SABlKnkvksi6CsqVeCy2WzL2OlSMD+S1YazbdtkpR0o=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=Bc46LRBGiGjkerIyEr5qGMg/VLY79lvQUT9s/rYJrEL3LM/N6Dn4YXLyI133SU0XW aVf+KIaxjbT6l0n81PNaiAdeAPwfw7FSW4KFnX3e83bTh5HRaJuZf2lrOX4QvnTM+m RrSvEh6va9hLZES3nvol/1mZx8WH7qb2eWjXW2qA= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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 5FC523858400 for ; Mon, 18 Oct 2021 12:14:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5FC523858400 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-328-HWt4bQS1MAurbywnbDapUQ-1; Mon, 18 Oct 2021 08:14:33 -0400 X-MC-Unique: HWt4bQS1MAurbywnbDapUQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 272D78066F3 for ; Mon, 18 Oct 2021 12:14:33 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.172]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B56CE194B9; Mon, 18 Oct 2021 12:14:30 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 19ICESXf2430565 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 18 Oct 2021 14:14:28 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 19ICERxw2430564; Mon, 18 Oct 2021 14:14:27 +0200 Date: Mon, 18 Oct 2021 14:14:27 +0200 To: Jason Merrill Subject: [PATCH] c++: Don't reject calls through PMF during constant evaluation [PR102786] Message-ID: <20211018121427.GZ304296@tucnak> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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-Patchwork-Original-From: Jakub Jelinek via Gcc-patches From: Jakub Jelinek Reply-To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Hi! The following testcase incorrectly rejects the c initializer, while in the s.*a case cxx_eval_* sees .__pfn reads etc., in the s.*&S::foo case get_member_function_from_ptrfunc creates expressions which use INTEGER_CSTs with type of pointer to METHOD_TYPE. And cxx_eval_constant_expression rejects any INTEGER_CSTs with pointer type if they aren't 0. Either we'd need to make sure we defer such folding till cp_fold but the function and pfn_from_ptrmemfunc is used from lots of places, or the following patch just tries to reject only non-zero INTEGER_CSTs with pointer types if they don't point to METHOD_TYPE in the hope that all such INTEGER_CSTs with POINTER_TYPE to METHOD_TYPE are result of folding valid pointer-to-member function expressions. I don't immediately see how one could create such INTEGER_CSTs otherwise, cast of integers to PMF is rejected and would have the PMF RECORD_TYPE anyway, etc. Regtested on x86_64-linux (with GXX_TESTSUITE_STDS=98,11,14,17,20,2b make check-g++) ok for trunk if it passes full bootstrap/regtest? 2021-10-18 Jakub Jelinek PR c++/102786 * constexpr.c (cxx_eval_constant_expression): Don't reject INTEGER_CSTs with type POINTER_TYPE to METHOD_TYPE. * g++.dg/cpp2a/constexpr-virtual19.C: New test. Jakub --- gcc/cp/constexpr.c.jj 2021-10-15 11:59:15.917687093 +0200 +++ gcc/cp/constexpr.c 2021-10-18 13:26:49.458610657 +0200 @@ -6191,6 +6191,7 @@ cxx_eval_constant_expression (const cons if (TREE_CODE (t) == INTEGER_CST && TYPE_PTR_P (TREE_TYPE (t)) + && TREE_CODE (TREE_TYPE (TREE_TYPE (t))) != METHOD_TYPE && !integer_zerop (t)) { if (!ctx->quiet) --- gcc/testsuite/g++.dg/cpp2a/constexpr-virtual19.C.jj 2021-10-18 13:35:00.229693908 +0200 +++ gcc/testsuite/g++.dg/cpp2a/constexpr-virtual19.C 2021-10-18 12:31:05.265747723 +0200 @@ -0,0 +1,11 @@ +// PR c++/102786 +// { dg-do compile { target c++20 } } + +struct S { + virtual constexpr int foo () const { return 42; } +}; + +constexpr S s; +constexpr auto a = &S::foo; +constexpr auto b = (s.*a) (); +constexpr auto c = (s.*&S::foo) ();