On Wed, Apr 20, 2011 at 9:06 PM, Xinliang David Li <davi...@google.com> wrote: > On Wed, Apr 20, 2011 at 12:03 PM, Cary Coutant <ccout...@google.com> wrote: >>> This brings out 2 questions. Why don't GCC 4.4/4.6/4.7 warn it? >>> Why doesn't 64bit GCC 4.2 warn it? >> >> Good question. It seems that the difference is whether the compiler >> generates a field-by-field copy or a call to memcpy(). According to >> David, the trunk gcc in 32-bit mode doesn't call memcpy, but still >> doesn't warn. He's looking at it. > > It seems to be related to alias rewrite -- the use of single memory > token somehow blocks the warning (even though the struct read are > SRAed).
The warning never really worked by design. It worked by luck if a read used the default definition of a non-aliased VOP. Which made it work for simple testcases but almost never for real code. A real uninitialized warning for memory wouldn't be difficult to write using the alias walking machinery (just use walk_aliased_vdefs, stop on the first callback assuming that's an initialization, warn if you don't get any callback). It's just going to be expensive. Richard.