[Bug analyzer/103892] -Wanalyzer-double-free false positive when compiling libpipeline

2022-01-14 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-01-14
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from David Malcolm  ---
Thanks for filing this; it does indeed look like a false positive.

I can reproduce it with trunk; will investigate further.

[Bug analyzer/103892] -Wanalyzer-double-free false positive when compiling libpipeline

2022-04-08 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892

--- Comment #2 from David Malcolm  ---
Still affects trunk

[Bug analyzer/103892] -Wanalyzer-double-free false positive when compiling libpipeline

2022-04-09 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892

--- Comment #3 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:3d41408c5d28105e7a3ea2eb2529431a70b96369

commit r12-8071-g3d41408c5d28105e7a3ea2eb2529431a70b96369
Author: David Malcolm 
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 

[Bug analyzer/103892] -Wanalyzer-double-free false positive when compiling libpipeline

2022-04-09 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892

David Malcolm  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from David Malcolm  ---
Should be fixed by the above patch on trunk for GCC 12.  Backporting the fix to
GCC 11 is probably not feasible.

Marking as resolved.

Thanks again for filing this bug.