https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
--- Comment #8 from Martin Sebor <msebor at gcc dot gnu.org> --- You're right, the test cases aren't equivalent, or meant to be. What I want to highlight is that in the test case in comment #6, in g() and other similar ones like it the warning is most likely going to be a false positive, while in h(), not warning most likely a false negative. Both of these "problems" are due to the same underlying assumption: that a variable whose address escapes may be modified by a subsequent call to an unknown function. The upshot is that the warning (indeed, all flow-based warnings) should consider not just what can be proven might happen based on the IL but also the likelihood with which it might happen. I'm not saying there's a coding bug in the implementation of the warning, rather that the heuristics it implements aren't sufficient to capture this distinction.
