public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: "Floyd, Paul" <paulf@free.fr>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: Safe transposition of logical and operands
Date: Mon, 18 Sep 2023 16:55:47 +0200	[thread overview]
Message-ID: <CAFiYyc3G6u8_pRaw22YOz5RckVwY7qw0ZKGLiO8-7=KW0w03rg@mail.gmail.com> (raw)
In-Reply-To: <d5f5c721-46a9-4ca9-8195-a2df602a1f51@free.fr>

On Mon, Sep 18, 2023 at 4:49 PM Floyd, Paul via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi Richard and Jonathan
>
> On 18/09/2023 10:00, Richard Biener wrote:
> > On Mon, Sep 18, 2023 at 9:24 AM Jonathan Wakely via Gcc<gcc@gcc.gnu.org>  wrote:
> >> Yes, GCC assumes that the reference is bound to a valid object, because C++
> >> requires that to be true. Of course memcheck can't assume that, because one
> >> of its main reasons to exist is to find undefined behaviour where that
> >> isn't true!
>
> It's even worse than that. This transformation is being done in VEX
> (which unfortunately
> is also the bit I know the least). Not normally where we'd do
> accessibility checks.
>
> >> I think what GCC is doing is a valid transformation, in the context of a
> >> valid C++ program. But I'm not sure that helps valgrind, which doesn't have
> >> the liberty of assuming a valid program.
> > More specifically GCC thinks it's fine to speculate loads (given it can prove
> > doing so doesn't trap)
>
> I don't think that will be easy for us to prove. We just don't know
> enough about stack variables.

What you could do is report the access only on the point of use of
the accessed value?  (and disregard when the register holding the
value is re-used)

Richard.

> A+
>
> Paui

  reply	other threads:[~2023-09-18 14:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-17 19:33 Paul Floyd
2023-09-17 20:51 ` Jonathan Wakely
2023-09-18  7:03   ` Paul Floyd
2023-09-18  7:23     ` Jonathan Wakely
2023-09-18  8:00       ` Richard Biener
2023-09-18 14:46         ` Floyd, Paul
2023-09-18 14:55           ` Richard Biener [this message]
2023-09-18 17:56             ` Paul Floyd
2023-09-18 19:09               ` Martin Uecker
2023-09-18 20:15                 ` Paul Floyd
2023-09-18 20:52                   ` Martin Uecker
2023-09-19  5:03                     ` Paul Floyd
2023-09-18  9:36       ` Jonathan Wakely
2023-09-18 10:30 ` Andreas Schwab

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='CAFiYyc3G6u8_pRaw22YOz5RckVwY7qw0ZKGLiO8-7=KW0w03rg@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=paulf@free.fr \
    /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).