[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event

["dmalcolm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188

--- Comment #7 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks.  I see a similar deluge of
  "terminating analysis for this program point"
warnings, but at different locations.

My warnings eventually terminate with:

  bzip2.c:1537:31: warning: analysis bailed out early (4561 'after-snode'
enodes; 15071 enodes) [-Wanalyzer-too-complex]

whereas yours don't - my machine is eventually hitting the overall complexity
limit (as opposed to merely hitting the per-program-point limit).

If I add
  -fparam-analyzer-bb-explosion-factor=50
to try to get past that limit (the default for that param is 5) then I see the
-Wanalyzer-unsafe-call-within-signal-handler warnings you're seeing (it takes
quite a while to run).

As in comment #5, I think what's happening is some "random" aspect of the
analysis affecting the order in which the worklist is processed, which leads to
my machine terminating early and yours running to completion.

So there are at least four issues here:

(a) the reported bug: that -Wanalyzer-unsafe-call-within-signal-handler uses
the wrong source location when reporting the signal registration event in the
diagnostic_path
(b) that -fanalyzer is hitting per-program-point limits
(c) that -fanalyzer can hit the overall enode limit
(d) that the behavior is sufficiently "random" that (c) can happen on one
machine and not on another, and that the log for the (b) events shows the order
of exploration varying between machines.

Mark: please can you add -fdump-analyzer-supergraph to the arguments and attach
the bzip2.c.supergraph.dot file to this bug.  Doing so may help track down (d).