On 1/27/20 2:02 PM, Jeff Law wrote:
[snip]
While I think we've missed the boat for gcc-10, I think these patches
should go forward in gcc-11. I'll own getting the paths sorted so that
this problem is avoided.
I recently retested these patches on trunk, and I found some new
regressions in the analyzer tests.
FAIL: default/gcc.sum:gcc.dg/analyzer/edges-1.c (test for bogus
messages, line 16)
This one may be a genuine analyzer bug? It is apparently failing to
prune the control flow paths per commit
004f2c07b6d3fa543f0fe86c55a7b3c227de2bb6.
PASS -> FAIL: default/gcc.sum:gcc.dg/analyzer/explode-2.c (test for
warnings, line 39)
PASS -> FAIL: default/gcc.sum:gcc.dg/analyzer/explode-2.c (test for
warnings, line 46)
PASS -> FAIL: default/gcc.sum:gcc.dg/analyzer/explode-2.c (test for
excess errors)
This one is hitting the "--Wanalyzer-too-complex" diagnostic and could
probably be fixed by adjusting the parameters at the top of the testcase.
PASS -> FAIL: default/gcc.sum:gcc.dg/analyzer/loop-4.c (test for
warnings, line 28)
PASS -> FAIL: default/gcc.sum:gcc.dg/analyzer/loop-4.c (test for
warnings, line 37)
PASS -> FAIL: default/gcc.sum:gcc.dg/analyzer/loop-4.c (test for excess
errors)
It's now printing "2 processed enodes" in both warnings instead of 3 or
4 (respectively). At first glance, it's not obvious what the
significance of the the things being tested here is, so I'm not sure if
this is an analyzer bug or just patterns that are too fragile.
David, WDYT?
-Sandra
