This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ubsan build of GCC 6.0 fails with: cp/search.c:1011:41: error: 'otype' may be used uninitialized in this function

On 09/09/2015 01:17 PM, Martin Sebor wrote:
On 09/09/2015 12:36 PM, Toon Moene wrote:

Full error message:

/home/toon/compilers/trunk/gcc/cp/search.c: In function 'int
accessible_p(tree, tree, bool)':
/home/toon/compilers/trunk/gcc/cp/search.c:1011:41: error: 'otype' may
be used uninitialized in this function [-Werror=maybe-uninitialized]
    dfs_accessible_data d = { decl, otype };
Any ideas ?

It looks as though GCC assumes that TYPE can be null even though
it can't (if it was, TYPE_P (type) would then dereference a null
pointer). As a workaround until this is fixed, initializing OTYPE
with type instead of in the else block should get rid of the error.

Here's a small test case that reproduces the bogus warning:

cat t.c && /build/gcc-trunk/gcc/xg++ -B /build/gcc-trunk/gcc
-Wmaybe-uninitialized -O2 -c -fsanitize=undefined t.c
struct S { struct S *next; int i; };

int foo (struct S *s) {
     int i;

     if (s->i) {
         struct S *p;
         for (p = s; p; p = p->next)
             i = p->i;
         i = 0;

     return i;
t.c: In function âint foo(S*)â:
t.c:14:12: warning: âiâ may be used uninitialized in this function
      return i;
More likely than not, the sanitization bits get in the way of VRP + jump threading rotating the loop.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]