public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc(refs/users/aoliva/heads/testme)] Accept pmf-vbit-in-delta extra warning
Date: Wed, 22 Feb 2023 14:49:18 +0000 (GMT)	[thread overview]
Message-ID: <20230222144918.088CA385828D@sourceware.org> (raw)

https://gcc.gnu.org/g:affa36e396a3dced8be3b7da92e302323ed79a44

commit affa36e396a3dced8be3b7da92e302323ed79a44
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Thu Feb 16 06:52:15 2023 -0300

    Accept pmf-vbit-in-delta extra warning
    
    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
    this patch only arranges for the test to tolerate the extra warning.
    
    
    for  gcc/testsuite/ChangeLog
    
            * g++.dg/warn/Waddress-5.C: Tolerate extra -Waddress warning.

Diff:
---
 gcc/testsuite/g++.dg/warn/Waddress-5.C | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/warn/Waddress-5.C b/gcc/testsuite/g++.dg/warn/Waddress-5.C
index b1287b2fac3..1de88076f77 100644
--- a/gcc/testsuite/g++.dg/warn/Waddress-5.C
+++ b/gcc/testsuite/g++.dg/warn/Waddress-5.C
@@ -23,7 +23,11 @@ void T (bool);
 void warn_memptr_if ()
 {
   // Exercise warnings for addresses of nonstatic member functions.
-  if (&A::f == 0)         // { dg-warning "the address '&A::f'" }
+  // On targets with TARGET_PTRMEMFUNC_VBIT_LOCATION ==
+  // ptrmemfunc_vbit_in_delta, cp_build_binary_op recurses to compare
+  // the pfn from the ptrmemfunc with null, so we get two warnings.
+  // This matches both.  ??? Should we disable one of them?
+  if (&A::f == 0)         // { dg-warning "A::f" }
     T (0);
 
   if (&A::vf)             // { dg-warning "-Waddress" }

             reply	other threads:[~2023-02-22 14:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-22 14:49 Alexandre Oliva [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-02-16 11:12 Alexandre Oliva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230222144918.088CA385828D@sourceware.org \
    --to=aoliva@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).