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;
| ^
