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" }
next 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: linkBe 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).