From: Alexandre Oliva <oliva@adacore.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: gcc-patches@gcc.gnu.org, msebor@redhat.com
Subject: Re: [PATCH] -Wdangling-pointer: don't mark SSA lhs sets as stores
Date: Fri, 17 Feb 2023 05:35:07 -0300 [thread overview]
Message-ID: <or8rgwr8p0.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <CAFiYyc1-Zw3P=Fji+hf-RxW83O=JLZDzvSfMKDYhi=aQkC6Xgw@mail.gmail.com> (Richard Biener's message of "Fri, 17 Feb 2023 08:53:00 +0100")
Hi, richi,
On Feb 17, 2023, Richard Biener <richard.guenther@gmail.com> wrote:
> It seems the case should run into
Yeah, but when the stmt is _7 = this_2(D), lhs is _7, whereas
lhs_ref.ref is this_2(D), a parm decl's default def, so def_stmt is a
gimple_nop, and this is not a decl_by_reference, so we don't skip
stores.add, and any subsequent stores into fields of *this fails
stores.add. This looks so fishy that I couldn't guess what was supposed
or expected to happen there :-(
> ? I wonder what the circumstances are that we want the latter to happen if
> the former condition is true?
Note that what I'm testing for, to skip non-store stmts, is the actual
lhs, whereas lhs_ref.ref may very well have been resolved to the rhs (as
in the cases I saw), and even if it could be an SSA_NAME, whether the
stmt is a store depends on the actual lhs, not on properties of the rhs
that get_ref resolved lhs to, right?
Now, really, I did not get as far as trying to make sense of the
algorithm in there (get_ref definitely doesn't do what its name suggests
to me), I just saw a bunch of weirdnesses in blackbox testing and
failing variations, that seemed to suggest some fundamental issue, that
would hopefully be obvious to someone more familiar with that code.
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about <https://stallmansupport.org>
next prev parent reply other threads:[~2023-02-17 8:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 7:09 Alexandre Oliva
2023-02-17 7:53 ` Richard Biener
2023-02-17 8:35 ` Alexandre Oliva [this message]
2023-02-17 9:09 ` Alexandre Oliva
2023-03-03 8:30 ` Alexandre Oliva
2023-03-03 11:12 ` Richard Biener
2023-03-08 13:04 ` Martin Liška
2023-03-08 13:08 ` Richard Biener
2023-03-09 8: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=or8rgwr8p0.fsf@lxoliva.fsfla.org \
--to=oliva@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=msebor@redhat.com \
--cc=richard.guenther@gmail.com \
/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).