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)] testsuite: Accept pmf-vbit-in-delta extra warning
Date: Thu, 23 Feb 2023 13:48:19 +0000 (GMT)	[thread overview]
Message-ID: <20230223134819.6473F3857803@sourceware.org> (raw)

https://gcc.gnu.org/g:21d0765370c2de59412114759447950289af2b44

commit 21d0765370c2de59412114759447950289af2b44
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Thu Feb 23 10:30:24 2023 -0300

    testsuite: 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:

             reply	other threads:[~2023-02-23 13:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-23 13:48 Alexandre Oliva [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-02-22 17:23 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=20230223134819.6473F3857803@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).