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