On Tue, 2022-01-25 at 11:47 -0500, Steve Grubb wrote: > Hello Dave, > > On Tuesday, January 25, 2022 9:29:53 AM EST David Malcolm wrote: > > Steve, thanks for putting together these cases. > > > > I've filed: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104224 > > against the gcc analyzer upstream to help me track improving the > > analyzer on this. > > > > OK if I go ahead and slurp this into the upstream gcc testsuite? > > Sure, go ahead. Thanks; done: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9ff3e2368d86c1bf7d1e8876a14e58c0d6617ffe In doing so I noticed that the analyzer was failing to check for uninit in some special-cases (for stdio functions), and so it was failing to warn for the: printf("go :%d\n", go); case. The patch above fixes that. > But I guess the global variable test cases can be removed > since the standard says they should be initialized to 0. (I thought > only > static got that treatment but found out otherwise.) I kept them, as it's valuable to check that we don't issue a false positive for such code (expressed via the "dg-bogus" directives in the above patch). > > > What optimization level were you running -fanalyzer at? > > I was doing all tests at -O2 since that is how things go through the > build > system. And based on other reports in this thread, it really affects > the > detection of tools - which is a pity, since a compile at -O2 is what we > get > via gating tests. > > > (Unfortunately the analyzer is currently affected by that; I'm > > thinking of > > moving the analysis pass much earlier so that it isn't). > > > > Running this on Compiler Explorer with gcc trunk with -fanalyzer (no > > optimizations) is: > > https://godbolt.org/z/T17TbqYdx > > Interesting. I was also using it with -fanalyzer-verbosity=0 to try > to get > a concise warning without following all the branches it used to decide. I'm experimenting with patches to avoid reporting on unrelated contol flow, to see if this will make the default verbosity level more readable. I've also added events describing where the uninit region of memory is created (stack vs heap), in: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=00e7d024afb80e95fb36d74b1c059468d883a850 which will hopefully be live in Compiler Explorer within the next 24 hours. > > Also, the tests that I wrote are a starting point. I didn't try > anything heap > related, For the stack, consider alloca as well as local vars. For the heap, consider malloc (no init) vs calloc (zero-init). > as parameters to syscalls, shift operations, floating point > calculations, or mathematical expressions. I believe -fanalyzer handles all of these cases [1]; I'll add explicit test coverage for them to the GCC testsuite. > I also did not touch on C++ at > all. To really quantify how the various tools stack up (and hopefully > to > improve detection), we need a good, curated collection of bugs. FWIW I've been experimenting with the Juliet test suite from SARD: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102471 and I've fixed at least one -fanalyzer bug found by running that suite (a leak false-positive). I'm very interested in any more feedback or ideas you (or others) have on this (including ideas for test cases). Thanks Dave [1] implementation-wise: due to all of these going through a check for uninit values in region_model::get_rvalue; GCC 12's -fanalyzer is tracking initialization at the per-bit level _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
