From: Jason Merrill <jason@redhat.com>
To: Alexandre Oliva <oliva@adacore.com>, gcc-patches@gcc.gnu.org
Cc: 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
Subject: Re: [PATCH] Accept pmf-vbit-in-delta extra warning
Date: Fri, 17 Feb 2023 12:11:03 -0500 [thread overview]
Message-ID: <e5017c7b-721f-9d5b-e019-a3e94917a6a6@redhat.com> (raw)
In-Reply-To: <orwn4gsrkk.fsf@lxoliva.fsfla.org>
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)
?
> this patch only arranges for the test to tolerate the extra warning.
>
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install?
OK
> for gcc/testsuite/ChangeLog
>
> * g++.dg/warn/Waddress-5.C: Tolerate extra -Waddress warning.
> ---
> 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 b1287b2fac316..1de88076f7767 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 prev parent reply other threads:[~2023-02-17 17:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 7:02 Alexandre Oliva
2023-02-17 17:11 ` Jason Merrill [this message]
2023-02-22 16:03 ` Alexandre Oliva
2023-02-28 14:14 ` Jason Merrill
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=e5017c7b-721f-9d5b-e019-a3e94917a6a6@redhat.com \
--to=jason@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=kyrylo.tkachov@arm.com \
--cc=mikestump@comcast.net \
--cc=nathan@acm.org \
--cc=nickc@redhat.com \
--cc=oliva@adacore.com \
--cc=ramana.gcc@gmail.com \
--cc=richard.earnshaw@arm.com \
--cc=ro@CeBiTec.Uni-Bielefeld.DE \
/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).