public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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 06:09:19 -0300	[thread overview]
Message-ID: <or4jrkr740.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <or8rgwr8p0.fsf@lxoliva.fsfla.org> (Alexandre Oliva's message of "Fri, 17 Feb 2023 05:35:07 -0300")

On Feb 17, 2023, Alexandre Oliva <oliva@adacore.com> wrote:

> 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.

Here's one more: the stores hash_set seems to be intended to help catch
overwrites, so as to detect assignments of pointers-to-auto-locals to
escaping pointers that reach exits, without flagging those that are
definitely overwritten afterwards.

In a linear backwards scan, that makes sense, but once blocks recurse
for their preds, ISTM it could suppress the desired warning in e.g.:

  if (condition)
    *incoming_ptr = &localvar;
  else
    *incoming_ptr = 0;

in case we scan the else bb before the then bb.


But how about asynchronous exceptions?  They might leave those dangling
pointers if they hit at an undesirable spot.  So should we really
suppress those warnings?

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

  reply	other threads:[~2023-02-17  9:11 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
2023-02-17  9:09     ` Alexandre Oliva [this message]
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=or4jrkr740.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).