* GCC not detecting use of uninitialized variable?
@ 2021-10-27 20:12 Alan Stern
2021-10-27 20:48 ` Willy Tarreau
0 siblings, 1 reply; 5+ messages in thread
From: Alan Stern @ 2021-10-27 20:12 UTC (permalink / raw)
To: Kernel development list
The following code does not generate a warning when compiled with GCC
11.2.1:
int foo;
void cc_test(void)
{
int a, b;
a = 0;
a = READ_ONCE(foo); // Should be: b = READ_ONCE(foo)
do {
a += b;
b = READ_ONCE(foo);
} while (a > 0);
WRITE_ONCE(foo, a);
}
But if the loop is changed to execute only once -- replace the while
test with "while (0)" -- then gcc does warn about the uninitialized use
of b.
Is this a known problem with gcc? Is it being too conservative about
detecting uses of uninitialized variables?
Alan Stern
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: GCC not detecting use of uninitialized variable? 2021-10-27 20:12 GCC not detecting use of uninitialized variable? Alan Stern @ 2021-10-27 20:48 ` Willy Tarreau 2021-10-28 1:47 ` Alan Stern 0 siblings, 1 reply; 5+ messages in thread From: Willy Tarreau @ 2021-10-27 20:48 UTC (permalink / raw) To: Alan Stern; +Cc: Kernel development list On Wed, Oct 27, 2021 at 04:12:49PM -0400, Alan Stern wrote: > The following code does not generate a warning when compiled with GCC > 11.2.1: > > > int foo; > > void cc_test(void) > { > int a, b; > > a = 0; > a = READ_ONCE(foo); // Should be: b = READ_ONCE(foo) > do { > a += b; > b = READ_ONCE(foo); > } while (a > 0); > WRITE_ONCE(foo, a); > } > > > But if the loop is changed to execute only once -- replace the while > test with "while (0)" -- then gcc does warn about the uninitialized use > of b. > > Is this a known problem with gcc? Is it being too conservative about > detecting uses of uninitialized variables? I already had similar issues not being detected in loops. I guess the reason is simple: it might not be trivial for the compiler to prove that the value was not set on any path leading to the first use, because one of these paths is the loop itself after the instruction was assigned. I've been so much used to it that I think it has always been there and I can live with it. Willy ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: GCC not detecting use of uninitialized variable? 2021-10-27 20:48 ` Willy Tarreau @ 2021-10-28 1:47 ` Alan Stern 2021-10-28 2:35 ` Willy Tarreau 0 siblings, 1 reply; 5+ messages in thread From: Alan Stern @ 2021-10-28 1:47 UTC (permalink / raw) To: Willy Tarreau; +Cc: Kernel development list On Wed, Oct 27, 2021 at 10:48:31PM +0200, Willy Tarreau wrote: > On Wed, Oct 27, 2021 at 04:12:49PM -0400, Alan Stern wrote: > > The following code does not generate a warning when compiled with GCC > > 11.2.1: > > > > > > int foo; > > > > void cc_test(void) > > { > > int a, b; > > > > a = 0; > > a = READ_ONCE(foo); // Should be: b = READ_ONCE(foo) > > do { > > a += b; > > b = READ_ONCE(foo); > > } while (a > 0); > > WRITE_ONCE(foo, a); > > } > > > > > > But if the loop is changed to execute only once -- replace the while > > test with "while (0)" -- then gcc does warn about the uninitialized use > > of b. > > > > Is this a known problem with gcc? Is it being too conservative about > > detecting uses of uninitialized variables? > > I already had similar issues not being detected in loops. I guess the > reason is simple: it might not be trivial for the compiler to prove > that the value was not set on any path leading to the first use, > because one of these paths is the loop itself after the instruction was > assigned. I've been so much used to it that I think it has always been > there and I can live with it. Well, in this case there's only one path leading to the first use, since the path that is the loop itself will never be the first use. It seems like a rather surprising oversight. Maybe I'll try asking the GCC people about this... Thanks, Alan Stern ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: GCC not detecting use of uninitialized variable? 2021-10-28 1:47 ` Alan Stern @ 2021-10-28 2:35 ` Willy Tarreau 2021-10-28 15:24 ` Alan Stern 0 siblings, 1 reply; 5+ messages in thread From: Willy Tarreau @ 2021-10-28 2:35 UTC (permalink / raw) To: Alan Stern; +Cc: Kernel development list On Wed, Oct 27, 2021 at 09:47:31PM -0400, Alan Stern wrote: > On Wed, Oct 27, 2021 at 10:48:31PM +0200, Willy Tarreau wrote: > > On Wed, Oct 27, 2021 at 04:12:49PM -0400, Alan Stern wrote: > > > The following code does not generate a warning when compiled with GCC > > > 11.2.1: > > > > > > > > > int foo; > > > > > > void cc_test(void) > > > { > > > int a, b; > > > > > > a = 0; > > > a = READ_ONCE(foo); // Should be: b = READ_ONCE(foo) > > > do { > > > a += b; > > > b = READ_ONCE(foo); > > > } while (a > 0); > > > WRITE_ONCE(foo, a); > > > } > > > > > > > > > But if the loop is changed to execute only once -- replace the while > > > test with "while (0)" -- then gcc does warn about the uninitialized use > > > of b. > > > > > > Is this a known problem with gcc? Is it being too conservative about > > > detecting uses of uninitialized variables? > > > > I already had similar issues not being detected in loops. I guess the > > reason is simple: it might not be trivial for the compiler to prove > > that the value was not set on any path leading to the first use, > > because one of these paths is the loop itself after the instruction was > > assigned. I've been so much used to it that I think it has always been > > there and I can live with it. > > Well, in this case there's only one path leading to the first use, since > the path that is the loop itself will never be the first use. It seems > like a rather surprising oversight. For the first iteration yes but not the next ones. And each time I met a similar bug not being detected it was exactly in this situation. For example the warning about "variable X is set but not used" tends to disappear in such loops: extern int blah(); int ret() { int a; do { a = 1; } while (blah()); return 0; } says "variable 'a' is set but not used". Just change "a=1" to "a++" and it disappears: extern int blah(); int ret() { int a; do { a++; } while (blah()); return 0; } And the asm code shows that the a++ code is optimized away, explaining why there is no "may be used uninitialized" while it appears if you return a instead of 0. With that said, it could also depend on the gcc version and/or some kernel options, as gcc-7, 8 and 9 do emit the warning for me on your code when I build it by hand. You may want to double-check this aspect before asking GCC people. Willy ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: GCC not detecting use of uninitialized variable? 2021-10-28 2:35 ` Willy Tarreau @ 2021-10-28 15:24 ` Alan Stern 0 siblings, 0 replies; 5+ messages in thread From: Alan Stern @ 2021-10-28 15:24 UTC (permalink / raw) To: Willy Tarreau; +Cc: Kernel development list On Thu, Oct 28, 2021 at 04:35:54AM +0200, Willy Tarreau wrote: > On Wed, Oct 27, 2021 at 09:47:31PM -0400, Alan Stern wrote: > > On Wed, Oct 27, 2021 at 10:48:31PM +0200, Willy Tarreau wrote: > > > On Wed, Oct 27, 2021 at 04:12:49PM -0400, Alan Stern wrote: > > > > The following code does not generate a warning when compiled with GCC > > > > 11.2.1: > > > > > > > > > > > > int foo; > > > > > > > > void cc_test(void) > > > > { > > > > int a, b; > > > > > > > > a = 0; > > > > a = READ_ONCE(foo); // Should be: b = READ_ONCE(foo) > > > > do { > > > > a += b; > > > > b = READ_ONCE(foo); > > > > } while (a > 0); > > > > WRITE_ONCE(foo, a); > > > > } > > > > > > > > > > > > But if the loop is changed to execute only once -- replace the while > > > > test with "while (0)" -- then gcc does warn about the uninitialized use > > > > of b. > > > > > > > > Is this a known problem with gcc? Is it being too conservative about > > > > detecting uses of uninitialized variables? > > > > > > I already had similar issues not being detected in loops. I guess the > > > reason is simple: it might not be trivial for the compiler to prove > > > that the value was not set on any path leading to the first use, > > > because one of these paths is the loop itself after the instruction was > > > assigned. I've been so much used to it that I think it has always been > > > there and I can live with it. > > > > Well, in this case there's only one path leading to the first use, since > > the path that is the loop itself will never be the first use. It seems > > like a rather surprising oversight. > > For the first iteration yes but not the next ones. And each time I met > a similar bug not being detected it was exactly in this situation. For > example the warning about "variable X is set but not used" tends to > disappear in such loops: > > extern int blah(); > int ret() > { > int a; > do { a = 1; } while (blah()); > return 0; > } > > says "variable 'a' is set but not used". Just change "a=1" to "a++" and > it disappears: > > extern int blah(); > int ret() > { > int a; > do { a++; } while (blah()); > return 0; > } > > And the asm code shows that the a++ code is optimized away, explaining > why there is no "may be used uninitialized" while it appears if you > return a instead of 0. > > With that said, it could also depend on the gcc version and/or some > kernel options, as gcc-7, 8 and 9 do emit the warning for me on your > code when I build it by hand. You may want to double-check this > aspect before asking GCC people. Heh -- you're right about that! I did do a quick double-check. Converting the test program into standard C and compiling it outside the kernel's build environment, I get a "may be used uninitialized" warning when gcc is invoked with "-O2 -Wall" but not when it is invoked with just "-Wall". On the other hand, in the "while (0)" case I get "is used uninitialized" either way. In kernel builds, gcc is invoked with "-Wno-maybe-uninitialized". That certainly explains the result I see. But it doesn't explain why gcc fails to realize what happens the first time through a "do" loop. Such first-time iterations always occur (as opposed to "while" loops) -- there's no "may" about it! Alan ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-10-28 15:24 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-10-27 20:12 GCC not detecting use of uninitialized variable? Alan Stern 2021-10-27 20:48 ` Willy Tarreau 2021-10-28 1:47 ` Alan Stern 2021-10-28 2:35 ` Willy Tarreau 2021-10-28 15:24 ` Alan Stern
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox