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

[Jeff Law]

On 09/09/2015 01:17 PM, Martin Sebor wrote:
> On 09/09/2015 12:36 PM, Toon Moene wrote:
>> See:
>>
>> https://gcc.gnu.org/ml/gcc-testresults/2015-09/msg00699.html
>>
>> 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;
>      }
>      else
>          i = 0;
>
>      return i;
> }
> t.c: In function ‘int foo(S*)’:
> t.c:14:12: warning: ‘i’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>       return i;
More likely than not, the sanitization bits get in the way of VRP + jump 
threading rotating the loop.

jeff