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 965CE3858D33 for ; Tue, 28 Feb 2023 14:15:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 965CE3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677593704; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SP8FKXyV8NZplcs73CIQtDp04w4LOsWm6Io8FWUDBmM=; b=WsTsGhVkS+i/S9kNJgrGZOMGl3WUNaxDK8AT7N+H1mXwvT3FGwu3/ydJVoTS7+BtsTfs7U jxm9crktvXNrTQj63EbjR5cP3lb3U4ydAAkEgtvBUiyteonvbgOVgpDOkr71Rhf2FXGyqm jGo0gthB3Q60xvi1zo7mSbQhO07Oj5E= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-126-_SIXdFepNq6K5T4QpatSFQ-1; Tue, 28 Feb 2023 09:15:03 -0500 X-MC-Unique: _SIXdFepNq6K5T4QpatSFQ-1 Received: by mail-qv1-f72.google.com with SMTP id pv11-20020ad4548b000000b0056e96f4fd64so5210524qvb.15 for ; Tue, 28 Feb 2023 06:15:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SP8FKXyV8NZplcs73CIQtDp04w4LOsWm6Io8FWUDBmM=; b=cymSPLithpB2tR+g1tin882KfAqekVzh+KmaHRbgRNJ/43ikkFMX44geygKx0oyrTX oK3VBVs2/U4eSjPaR8WpugMs+rP4QmtLQRcB/nwDA2roGHRfKk4xeD0sHImEzAiwcEWw Q3JEybRLIWwEXBsCA3EiT6CLKEFeMUIRL9KCJHoYor7tStj38vrSi8joN3lVNu3x7QuN W/V0m3y+YTGF7elEPiJAr3DEl31rk7oZ3ZxTA+r2tWAO99rRtBOdXVf9Fx0y5x9oddNM E7emoEdseRqnLTRHIFiyBplHVdaEL2y4F3Po7vORDRuaI2xISEAcX3I8AWeAmU1Wwj5B pTnw== X-Gm-Message-State: AO0yUKWRAmFZ45oGvbcddcpgXQ5gpOV3NPSI+/NxYgGRIVtcBFffo9C9 XVUOSkYsWE2Etkt25yzZ3AdEB9m68BRRcIU0OQ+lxvP7YbNCFaM1WvvM+Ez9CucsoH2SoM9iURv RU/syR6DKun7ggXuppw== X-Received: by 2002:ac8:7f54:0:b0:3bf:c849:4971 with SMTP id g20-20020ac87f54000000b003bfc8494971mr4774672qtk.62.1677593702431; Tue, 28 Feb 2023 06:15:02 -0800 (PST) X-Google-Smtp-Source: AK7set8q/ZbIwoVJ0JLs2FibrvBSLuzkNelfB7tDKwQ9qMDen2mNAVgB6lcAN+X4gymTpgG486S5dA== X-Received: by 2002:ac8:7f54:0:b0:3bf:c849:4971 with SMTP id g20-20020ac87f54000000b003bfc8494971mr4774620qtk.62.1677593702063; Tue, 28 Feb 2023 06:15:02 -0800 (PST) Received: from [192.168.1.108] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id n15-20020ac81e0f000000b003b691385327sm4935698qtl.6.2023.02.28.06.15.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Feb 2023 06:15:01 -0800 (PST) Message-ID: Date: Tue, 28 Feb 2023 09:14:59 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] Accept pmf-vbit-in-delta extra warning To: Alexandre Oliva Cc: gcc-patches@gcc.gnu.org, nathan@acm.org, nickc@redhat.com, richard.earnshaw@arm.com, ramana.gcc@gmail.com, kyrylo.tkachov@arm.com, ro@CeBiTec.Uni-Bielefeld.DE, mikestump@comcast.net References: From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2/22/23 11:03, Alexandre Oliva wrote: > On Feb 17, 2023, Jason Merrill wrote: > >> On 2/17/23 23:02, Alexandre Oliva wrote: >>> >>> cp_build_binary_op, that issues -Waddress warnings, issues an extra >>> warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect >>> when comparing a pointer-to-member-function literal with null. >>> >>> The reason for the extra warning is that, on arm targets, >>> TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, which >>> causes a different path to be taken, that extracts the >>> pointer-to-function and the delta fields (minus the vbit) and compares >>> each one with zero. It's when comparing this pointer-to-function with >>> zero, in a recursive cp_build_binary_op, that another warning is >>> issued. >>> >>> I suppose there should be a way to skip the warning in this recursive >>> call, without disabling other warnings that might be issued there, but > >> warning_sentinel ws (warn_address) > > Oh, yeah, that will suppress the expected warning for pfn0, but isn't > there any risk whatsoever that it could suppress other -Waddress > warnings for tree operands of pfn0? There shouldn't be an issue; those operands would have been considered for warning when building their subexpressions. > I see the cp_save_expr for side effects, but what if e.g. the pmfn we're > testing is an array element, and the index expression tests another pmfn > against NULL that should be warned about? Or something else that > wouldn't have TREE_SIDE_EFFECTS, and would thus not go through > cp_save_expr. Would we then warn for uses of both pfn0 and delta0? > > > Here's what I'm going to test for these concerns. Ok to install if it > bootstraps successfully, and my concerns are unfounded? OK. > [c++] suppress redundant null-addr warn in pfn from pmfn > > From: Alexandre Oliva > > When TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, when > we warn about comparing a pointer-to-member-function with NULL, we > also warn about comparing the pointer-to-function extracted from it > with NULL, which is redundant. Suppress the redundant warning. > > > for gcc/cp/ChangeLog > > * typeck.cc (cp_build_binary_op): Suppress redundant warning > for pfn null test in pmfn test with vbit-in-delta. > --- > gcc/cp/typeck.cc | 17 ++++++++++++----- > 1 file changed, 12 insertions(+), 5 deletions(-) > > diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc > index 4afb5e4f0d420..d5a3e501d8e91 100644 > --- a/gcc/cp/typeck.cc > +++ b/gcc/cp/typeck.cc > @@ -5780,11 +5780,18 @@ cp_build_binary_op (const op_location_t &location, > > pfn0 = pfn_from_ptrmemfunc (op0); > delta0 = delta_from_ptrmemfunc (op0); > - e1 = cp_build_binary_op (location, > - EQ_EXPR, > - pfn0, > - build_zero_cst (TREE_TYPE (pfn0)), > - complain); > + { > + /* If we will warn below about a null-address compare > + involving the orig_op0 ptrmemfunc, we'd likely also > + warn about the pfn0's null-address compare, and > + that would be redundant, so suppress it. */ > + warning_sentinel ws (warn_address); > + e1 = cp_build_binary_op (location, > + EQ_EXPR, > + pfn0, > + build_zero_cst (TREE_TYPE (pfn0)), > + complain); > + } > e2 = cp_build_binary_op (location, > BIT_AND_EXPR, > delta0, > >