https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by David Malcolm <dmalc...@gcc.gnu.org>: https://gcc.gnu.org/g:1d9f3b7ad4f965a0acc21d42cb2d186ecd065b71 commit r11-7155-g1d9f3b7ad4f965a0acc21d42cb2d186ecd065b71 Author: David Malcolm <dmalc...@redhat.com> Date: Tue Feb 9 15:53:01 2021 -0500 analyzer: treat pointers written to *UNKNOWN as escaping [PR98575] PR analyzer/98575 describes an unexpected -Wanalyzer-malloc-leak false positive from gcc.dg/analyzer/pr94851-1.c on glibc < 2.28. The issue is that a getchar call gets inlined into a call to _IO_getc, and "_IO_getc" is not in the set of FILE * functions the analyzer "knows about". This leads to a global pointer struct buf *curbp; being treated as UNKNOWN after the call to _IO_getc. Later when a malloced pointer is written to curbp->b_amark, the write is discarded (since curbp is unknown) without noting that the pointer has escaped, and so the pointer is erroneously treated as leaking when the function returns. This patch updates the handling of *UNKNOWN to treat pointers written to them as having escaped, fixing the false positive. The patch stops the leak warning in gcc.dg/analyzer/explode-1.c. After merging states at the join-point after the first switch, pp has UNKNOWN value, and so *pp is a write through UNKNOWN, which with this patch is now treated as escaping - despite the fact that all possible values for *pp are on the stack. There doesn't seem to be a good way to fix this, and the testcase is an artifically constructed one, so the patch simply removes the dg-warning directive. gcc/analyzer/ChangeLog: PR analyzer/98575 * store.cc (store::set_value): Treat a pointer written to *UNKNOWN as having escaped. gcc/testsuite/ChangeLog: PR analyzer/98575 * gcc.dg/analyzer/explode-1.c: Remove expected leak warning. * gcc.dg/analyzer/pr94851-2.c: New test. * gcc.dg/analyzer/pr98575-1.c: New test.
