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 ESMTP id D2DA93858439 for ; Wed, 11 Aug 2021 19:20:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D2DA93858439 Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-518-MBhVmcgBNiOkgBJ9UT7T9w-1; Wed, 11 Aug 2021 15:20:01 -0400 X-MC-Unique: MBhVmcgBNiOkgBJ9UT7T9w-1 Received: by mail-qk1-f199.google.com with SMTP id b9-20020a05620a1269b02903b8bd5c7d95so1976160qkl.12 for ; Wed, 11 Aug 2021 12:20:01 -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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3QWymGuGYDn2S8bYot7xZpL37RVzEdNpPis1DIj2L80=; b=p9MAbmrECL+Eh7F+NGjnSWWJf7k1tUWuweLC7AUBUB5iWqZ9g219sAM2beP7hCNEMf 6BDKHWHGJamRTJtjj9flbmkvAo5fipAK5PsvPizPIm8Z5F1Akb+1g8mf0uNC8FfEcnjz kvNyejIrDBEnVybi/2FU6TVOjWH2ogG5THIDZSYLhXfLxk789sNDvHSO610syCWBYv7+ tUlSJ08VudcviVNK5YJ8UMaA81Q3bHrMhKkW8FML3tE+qp9mVnTFuGMVEhEoQf9dfi2h Yq2IV1jHPK0kY9H5ifo9g3R/RQOG7a5L6ALcNQWVClp7PqGDDn/EZHzq2UiEbHL68+V2 YJaA== X-Gm-Message-State: AOAM531EgBgWNRYV7ZWEMscIK4uoiAs2moXrw5dCnR1XdexBRfS01Q+u FuR46pOaLNMzlcTd/dzMLgBFnaX5HlSpO0zMUAgVTqVQYzStk+tjKN7rkKj9G5F0jz661IItkpD SuHM0nxwwH3N3aOA7ZQ== X-Received: by 2002:a37:a38d:: with SMTP id m135mr653349qke.222.1628709600843; Wed, 11 Aug 2021 12:20:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyCpRLQTh3lco83IfSSE8x8H1g0R/u9K2P9BstvPW07sI5xUHawXW6ZI+5Kq1WADKaaEAH6sQ== X-Received: by 2002:a37:a38d:: with SMTP id m135mr653329qke.222.1628709600585; Wed, 11 Aug 2021 12:20:00 -0700 (PDT) Received: from [192.168.1.148] (130-44-159-43.s11817.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id bl26sm50602qkb.34.2021.08.11.12.19.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Aug 2021 12:19:59 -0700 (PDT) Subject: Re: [PATCH] c++: suppress all warnings on memper pointers to work around dICE [PR101219] To: Sergei Trofimovich Cc: gcc-patches@gcc.gnu.org, Martin Sebor , Sergei Trofimovich References: <20210722231524.2045951-1-slyfox@gentoo.org> <67b15096-25fd-bf23-0be2-57af76462166@redhat.com> <20210806163428.06373da6@zn3> From: Jason Merrill Message-ID: <116cc93c-0839-87bd-ee30-bec924c9c9be@redhat.com> Date: Wed, 11 Aug 2021 15:19:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210806163428.06373da6@zn3> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.4 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_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-List-Received-Date: Wed, 11 Aug 2021 19:20:04 -0000 On 8/6/21 11:34 AM, Sergei Trofimovich wrote: > On Thu, 29 Jul 2021 11:41:39 -0400 > Jason Merrill wrote: > >> On 7/22/21 7:15 PM, Sergei Trofimovich wrote: >>> From: Sergei Trofimovich >>> >>> r12-1804 ("cp: add support for per-location warning groups.") among other >>> things removed warning suppression from a few places including ptrmemfuncs. >>> >>> Currently ptrmemfuncs don't have valid BINFO attached which causes ICEs >>> in access checks: >>> >>> crash_signal >>> gcc/toplev.c:328 >>> perform_or_defer_access_check(tree_node*, tree_node*, tree_node*, int, access_failure_info*) >>> gcc/cp/semantics.c:490 >>> finish_non_static_data_member(tree_node*, tree_node*, tree_node*) >>> gcc/cp/semantics.c:2208 >>> ... >>> >>> The change suppresses warnings again until we provide BINFOs for ptrmemfuncs. >> >> We don't need BINFOs for PMFs, we need to avoid paths that expect them. >> >> It looks like the problem is with tsubst_copy_and_build calling >> finish_non_static_data_member instead of build_ptrmemfunc_access_expr. > > Sounds good. I'm not sure what would be the best way to match it. Here is > my attempt seems to survive all regtests: > > --- a/gcc/cp/pt.c > +++ b/gcc/cp/pt.c > @@ -20530,7 +20530,13 @@ tsubst_copy_and_build (tree t, > if (member == error_mark_node) > RETURN (error_mark_node); > > - if (TREE_CODE (member) == FIELD_DECL) > + if (object_type && TYPE_PTRMEMFUNC_P(object_type) > + && TREE_CODE (member) == FIELD_DECL) > + { > + r = build_ptrmemfunc_access_expr (object, DECL_NAME(member)); > + RETURN (r); > + } > + else if (TREE_CODE (member) == FIELD_DECL) > { > r = finish_non_static_data_member (member, object, NULL_TREE); > if (TREE_CODE (r) == COMPONENT_REF) > >>> PR c++/101219 >>> >>> gcc/cp/ChangeLog: >>> >>> * typeck.c (build_ptrmemfunc_access_expr): Suppress all warnings >>> to avoid ICE. >>> >>> gcc/testsuite/ChangeLog: >>> >>> * g++.dg/torture/pr101219.C: New test. >> >> This doesn't need to be in torture; it has nothing to do with optimization. > > Aha, moved to gcc/testsuite/g++.dg/warn/pr101219.C. > > --- /dev/null > +++ b/gcc/testsuite/g++.dg/warn/pr101219.C > @@ -0,0 +1,11 @@ > +/* PR c++/101219 - ICE on use of uninitialized memfun pointer > + { dg-do compile } > + { dg-options "-Wall" } */ > + > +struct S { void m(); }; > + > +template bool f() { > + void (S::*mp)(); > + > + return &S::m == mp; // no warning emitted here (no instantiation) > +} > > Another question: Is it expected that gcc generates no warnings here? > It's an uninstantiated function (-1 for warn), but from what I > understand it's guaranteed to generate comparison with uninitialized > data if it ever gets instantiated. Given that we used to ICE in > warning code gcc could possibly flag it? (+1 for warn) Generally it's desirable to diagnose templates for which no valid instantiation is possible. It seems reasonable in most cases to also warn about templates for which all instantiations would warn. But uninitialized warnings rely on flow analysis that we only do on instantiated functions, and in any case the ICE doesn't depend on mp being uninitialized; I get the same crash if I add = 0 to the declaration. > + if (object_type && TYPE_PTRMEMFUNC_P(object_type) Missing space before (. > + && TREE_CODE (member) == FIELD_DECL) > + { > + r = build_ptrmemfunc_access_expr (object, DECL_NAME(member)); And here. Jason