On Thu, 4 Jun 2020 at 18:59, Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > 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.
Hi, This is causing a regression in fortran tests: FAIL: gfortran.dg/goacc/uninit-use-device-clause.f95 -O (test for warnings, line 7) FAIL: gfortran.dg/goacc/uninit-use-device-clause.f95 -O (test for excess errors) Excess errors: /gcc/testsuite/gfortran.dg/goacc/uninit-use-device-clause.f95:7:0: Warning: 'p' is used uninitialized [-Wuninitialized] Christophe > > 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 > > >
