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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id AB9863853C13 for ; Thu, 12 Aug 2021 14:38:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AB9863853C13 Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-471-5pW8ejbYNTifF-NItxeMvA-1; Thu, 12 Aug 2021 10:38:13 -0400 X-MC-Unique: 5pW8ejbYNTifF-NItxeMvA-1 Received: by mail-qv1-f71.google.com with SMTP id u11-20020ad45aab0000b029033e289c093aso3458362qvg.10 for ; Thu, 12 Aug 2021 07:38:13 -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=2s+zXxlocUzkX6eXK4pXA0LYGNJFcLYvjMBsRVSoN4Q=; b=RrS/P1a4FbG01rl9ls9+S8Ze4hPFsFiQZgJoTKH7h7A/+mjey8bENphpLeU6FBUICN ghHWwueNCx2tiujVaqLCC47WcTF4pbwpnG/RtBGqBMNDrELMFkEovyc0ReRg/N2HZVOk rj6BqqiC49bA6hQSVFtvHFwHZXeawjMCOCA/GQ4gBFl/ad6K1/hWPrMvUDhkX5gLycpv crtHYrP8SGQU8tfRawdwGgdQ/DFudXnnZovmIIOx56YRRV0nkapMnq7H63CpiBqGBU5p GopIJz96B+2Ks1fTjmDzltpFx4vw1u0RfyAOJ7Dl423zBOY6BIPuJ9gs56ik8VTQ7YX1 Ep9A== X-Gm-Message-State: AOAM530dmORglUmTrZb4qMwsc054Dz/foq39gTRzokkaNxA7XvKTSrn5 4xJge+79J7zCzARV5Y5suMCpjjNM27atcWZCd6NSYYsfpeL0MaTu2hmELtUDqCV406cXNjjPhaq 3xCNExzskUlikZiBomw== X-Received: by 2002:ad4:5d61:: with SMTP id fn1mr4272997qvb.32.1628779092853; Thu, 12 Aug 2021 07:38:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwRzprZM+jrulky/pvyUSES1xmm55/EsCBa++AhludmwTCr0/muN5JXryBaRqey84WFnn2N5g== X-Received: by 2002:ad4:5d61:: with SMTP id fn1mr4272967qvb.32.1628779092552; Thu, 12 Aug 2021 07:38:12 -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 m197sm1407854qke.54.2021.08.12.07.38.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Aug 2021 07:38:11 -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> <116cc93c-0839-87bd-ee30-bec924c9c9be@redhat.com> <20210811233642.55961437@zn3> From: Jason Merrill Message-ID: <67a3c9d4-2e3c-3b3f-3454-3bab7f5b6142@redhat.com> Date: Thu, 12 Aug 2021 10:38:10 -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: <20210811233642.55961437@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.3 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=unavailable 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: Thu, 12 Aug 2021 14:38:17 -0000 On 8/11/21 6:36 PM, Sergei Trofimovich wrote: > On Wed, 11 Aug 2021 15:19:58 -0400 > Jason Merrill wrote: > >> 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. > > Aha. That makes sense. Let's just fix ICE then. > >>> + 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. > > Added both. Attached as v3. OK, thanks. Jason