https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80824
Martin Sebor <msebor at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |msebor at gcc dot gnu.org Summary|Missing |Missing -Wuninitialized at |'variable-is-used-uninitial |-O0 due to conservative |ized' warning |aliasing assumptions Ever confirmed|0 |1 Known to fail| |10.2.0, 11.0, 7.3.0, 8.3.0, | |9.2.0 Last reconfirmed| |2021-04-02 --- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> --- Confirmed with GCC 11 and the slightly smaller test case below. With -O0, the warning is issued in the first case because GCC sees the initialization modifies just the two array elements and not s.b. It's not issued in the second case because the warning relies on the optimizer infrastructure to tell it if s.b might be modified and because the optimizer doesn't run at -O0 the constant values aren't propagated into the array dereferences and so the infrastructure (exceedingly conservatively) assumes that the accesses to s.a might modify other members of s. This is a downside of warnings using the same conservative assumptions as optimizers must. To do better, the warning would have to avoid some of these conservative assumptions. This isn't really a bug but a limitation inherent in most of these warnings. $ cat z.c && gcc -S -Wall z.c void f (void); int g (void) { f (); struct S { int a[2], b; } s; enum { i = 0, j = 1 }; s.a[i] = 0; s.a[j] = 0; return s.b; // -Wuninitialized } int h (void) { f (); struct S { int a[2], b; } s; int i = 0, j = 1; s.a[i] = 0; s.a[j] = 0; return s.b; // missing warning } z.c: In function ‘g’: z.c:12:11: warning: ‘s.b’ is used uninitialized [-Wuninitialized] 12 | return s.b; // -Wuninitialized | ~^~ z.c:7:29: note: ‘s’ declared here 7 | struct S { int a[2], b; } s; | ^