https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93355
--- Comment #9 from David Malcolm <dmalcolm at gcc dot gnu.org> --- Going back to the summary from comment #4: (a) It happens to successfully explore enough of the graph to find the leak, but hits complexity limits at a program point (b) Without -fno-analyzer-feasibility, it falsely rejects the path as infeasible (c) is effectively fixed by r11-7029-g8a2750086d57d1a2251d9239fa4e6c2dc9ec3a86. The issue with (a) is that we have a non-trivial function calling a non-trivial function, and the lack of call summaries means that we get a state explosion due to expanding the callee 3 times (once directly, and twice at the single callsite, exploded in the callee). The callee has an issue that is found standalone (since r11-7029-g8a2750086d57d1a2251d9239fa4e6c2dc9ec3a86). Hence the state explosion on nested calls means that we won't fail to find the standalone issue. So although it would be good to fix the state explosion/call summary issue, I think it's lower priority than fixing the feasibility issue. (I spent some time this week looking at call summaries, but now think this is lower priority than the feasibility issue). For (b), I've tried several approaches, but now that we're trying multiple paths per dedupe candidate, it's hard to see where things go wrong. I've been experimenting with better ways to visualize this to try to make debugging it less painful.
