On Feb 17, 2023, Alexandre Oliva <ol...@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>
