On Fri, 2020-05-15 at 17:31 -0600, Martin Sebor via Gcc-patches wrote: > Besides better buffer overflow checking, the new GCC 10 attribute > access also provides an opportunity to detect other kinds of bugs, > including uninitialized accesses by user-defined functions. > The attached patch implements this enhancement. > > In addition, the closely related PR 10138 requests that GCC warn when > passing the address of an uninitialized variable to a const-qualified > pointer function argument. Const pointers almost always imply a read > access of the object, so the patch also enables the warning in these > cases. (There are situations when a const pointer doesn't imply it > and the warning takes care not to trigger overly enthusiastically.) > Since pointers often point to allocated objects it seemed natural > (and was surprisingly easy) to also detect uninitialized reads from > those. > > For optimum results I slightly enhanced the detection of the referenced > decls and allocations. In the process, I also noticed and fixed a small > bug in the existing code. This helps both find more uninitialized > variables and reduce the rate of false positives in existing warnings. > > Besides the usual GCC bootstrap/regtest I validated the changes by > building a number of packages, including Binutils/GDB, Glibc, and > the Linux kernel. It found a decent number of likely bugs (about > half a doze by my count) but also triggered a few false positives. > One class of such problems was due to the kernel's function > > __check_object_size (const void*, unsigned, bool) > > used to validate the sizes of objects without ever accessing them. > To accommodate this idiom the patch adds a new mode to attribute > access: none. There's a minor typo in a comment within initialize_argument_information s/accewss/access/
I'm slightly concerned about the diagnostic wording change breaking scanners and such, but that's well outside what we consider stable release-to-release. So, OK. I think Bin has some work in tree-ssa-uninit.c that's been approved, but not merged yet and there may be conflicts (though no fundamental conceptual conflicts). I suggest committing immediately rather than waiting for Bin though -- I'll ping Bin on his change and let him know there's a notable potential for conflicts. jeff >
