https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892
--- Comment #3 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:3d41408c5d28105e7a3ea2eb2529431a70b96369 commit r12-8071-g3d41408c5d28105e7a3ea2eb2529431a70b96369 Author: David Malcolm <dmalc...@redhat.com> Date: Sat Apr 9 18:12:57 2022 -0400 analyzer: fix folding of regions involving unknown ptrs [PR103892] PR analyzer/103892 reports a false positive from -Wanalyzer-double-free. The root cause is the analyzer failing to properly handle "unknown" symbolic regions, and thus confusing two different expressions. Specifically, the analyzer eventually hits the complexity limit for symbolic values, and starts using an "unknown" svalue for a pointer. The analyzer uses symbolic_region(unknown_svalue([of ptr type])) i.e. (*UNKNOWN_PTR) in a few places to mean "we have an lvalue, but we're not going to attempt to track what it is anymore". "Unknown" should probably be renamed to "unknowable"; in theory, any operation on such an unknown svalue should be also an unknown svalue. The issue is that in various places where we create child regions, we were failing to check for the parent region being (*UNKNOWN_PTR), and so were erroneously creating regions based on (*UNKNOWN_PTR), such as *(UNKNOWN_PTR + OFFSET). The state-machine handling was erroneously allowing e.g. INITIAL_VALUE (*(UNKNOWN_PTR + OFFSET)) to have state, and thus we could record that such a value had had "free" called on it, and thus eventually false report a double-free when a different expression incorrectly "simplified" to the same expression. This patch fixes things by checking when creating the various kinds of child region for (*UNKNOWN_PTR) as the parent region, and simply returning another (*UNKNOWN_PTR) for such child regions (using the appropriate type). Doing so fixes the false positive, and also fixes a state explosion on this testcase, as the states at the program points more rapidly reach a fixed point where everything is unknown. I checked for other cases that no longer needed -Wno-analyzer-too-complex; the only other one seems to be gcc.dg/analyzer/pr96841.c, but that seems to already have become redundant at some point before this patch. gcc/analyzer/ChangeLog: PR analyzer/103892 * region-model-manager.cc (region_model_manager::get_unknown_symbolic_region): New, extracted from... (region_model_manager::get_field_region): ...here. (region_model_manager::get_element_region): Use it here. (region_model_manager::get_offset_region): Likewise. (region_model_manager::get_sized_region): Likewise. (region_model_manager::get_cast_region): Likewise. (region_model_manager::get_bit_range): Likewise. * region-model.h (region_model_manager::get_unknown_symbolic_region): New decl. * region.cc (symbolic_region::symbolic_region): Handle sval_ptr having NULL type. (symbolic_region::dump_to_pp): Handle having NULL type. gcc/testsuite/ChangeLog: PR analyzer/103892 * gcc.dg/analyzer/pr103892.c: New test. * gcc.dg/analyzer/pr96841.c: Drop redundant -Wno-analyzer-too-complex. Signed-off-by: David Malcolm <dmalc...@redhat.com>
