[Bug c/38961] New: if () block not true but a command in it is still in effect
Complete command line that triggered the bug: gcc -v -save-temps -ansi -Wall
-Wextra -Werror -pedantic -pedantic-errors -g -O2 -o gcc_bug gcc_bug.c
Output of the command line:
**
Reading specs from /usr/lib/gcc/i486-slackware-linux/4.2.4/specs
Target: i486-slackware-linux
Configured with: ../gcc-4.2.4/configure --prefix=/usr --enable-shared
--enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix
--enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose
--with-arch=i486 --target=i486-slackware-linux --host=i486-slackware-linux
Thread model: posix
gcc version 4.2.4
/usr/libexec/gcc/i486-slackware-linux/4.2.4/cc1 -E -quiet -v gcc_bug.c
-mtune=i486 -march=i486 -ansi -Wall -Wextra -Werror -pedantic -pedantic-errors
-fworking-directory -O2 -fpch-preprocess -o gcc_bug.i
ignoring nonexistent directory
"/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../../i486-slackware-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i486-slackware-linux/4.2.4/include
/usr/include
End of search list.
/usr/libexec/gcc/i486-slackware-linux/4.2.4/cc1 -fpreprocessed gcc_bug.i
-quiet -dumpbase gcc_bug.c -mtune=i486 -march=i486 -ansi -auxbase gcc_bug -g
-O2 -Wall -Wextra -Werror -pedantic -pedantic-errors -ansi -version -o
gcc_bug.s
GNU C version 4.2.4 (i486-slackware-linux)
compiled by GNU C version 4.2.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d3491cea3997204b3b932c449c79b80e
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../../i486-slackware-linux/bin/as
-V -Qy -o gcc_bug.o gcc_bug.s
GNU assembler version 2.18.50.0.9 (i486-slackware-linux) using BFD version
(Linux/GNU Binutils) 2.18.50.0.9.20080822
/usr/libexec/gcc/i486-slackware-linux/4.2.4/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o gcc_bug
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../crt1.o
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../crti.o
/usr/lib/gcc/i486-slackware-linux/4.2.4/crtbegin.o
-L/usr/lib/gcc/i486-slackware-linux/4.2.4
-L/usr/lib/gcc/i486-slackware-linux/4.2.4
-L/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../../i486-slackware-linux/lib
-L/usr/lib/gcc/i486-slackware-linux/4.2.4/../../.. gcc_bug.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i486-slackware-linux/4.2.4/crtend.o
/usr/lib/gcc/i486-slackware-linux/4.2.4/../../../crtn.o
**
The source code that triggered the bug:
**
#include
#include
const char *logout_cmd = NULL;
static void foo()
{
const char *logout_cmd = logout_cmd;
if ( ! logout_cmd )
{
/* This line is not executed. */
printf("line %d, logout_cmd = %s\n", __LINE__, logout_cmd);
/* This line is not executed when stepping through the code
* with gdb, but logout_cmd still is assigned the value
* "lxsession-logout", possible optimization bug? */
logout_cmd = "lxsession-logout";
}
printf("line %d, logout_cmd = %s\n", __LINE__, logout_cmd);
if (strcmp(logout_cmd, "openbox --exit"))
printf("gcc bug triggered\n");
}
int main(void)
{
printf("line %d, logout_cmd = %s\n", __LINE__, logout_cmd);
logout_cmd = "openbox --exit";
printf("line %d, logout_cmd = %s\n", __LINE__, logout_cmd);
foo();
printf("line %d, logout_cmd = %s\n", __LINE__, logout_cmd);
return 0;
}
**
--
Summary: if () block not true but a command in it is still in
effect
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jellegeerts at gmail dot com
GCC host triplet: i486-slackware-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #2 from jellegeerts at gmail dot com 2009-01-24 18:15 --- Yes, I know, but it is still a bug that the if () block is false and the variable is still assigned the "lxsession-logout" value but the printf is not executed. Shouldn't be possible I figured? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #4 from jellegeerts at gmail dot com 2009-01-24 18:44 --- That is certainly true, but shouldn't GCC (instead of optionally warning) report an error? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #6 from jellegeerts at gmail dot com 2009-01-24 22:24 --- Seems reasonable, though I'd vote for -Wall to include -Winit-self. I actually discovered this because of a bug I found in lxpanel. Now of course it's the fault of those developers not to use -Winit-self, but seen the other options that -Wall enables, it seems reasonable to also enable -Winit-self. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #8 from jellegeerts at gmail dot com 2009-01-25 01:50 --- So actually initializing the variable by itself is a hack which results in undefined behavior because folks wanted to disable the warning, and still everybody thinks this is the way to go? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c/38961] if () block not true but a command in it is still in effect
--- Comment #9 from jellegeerts at gmail dot com 2009-01-25 01:54 --- Never mind my last message, misunderstood something. Andrew, you say -Winit-self was added because initing a var by itself was a way to disable the -Wuninitialized warning, but shouldn't -Wuninitialized itself warn about the -Winit-self case? In the end it's still undefined behavior and it makes little sense to allow it (correct me if you have other ideas). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
[Bug c++/36814] G++ won't warn about an uninitialized value
--- Comment #2 from jellegeerts at gmail dot com 2008-08-18 18:14 --- Created an attachment (id=16086) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16086&action=view) output of G++ with the `-v -save-temps' flags -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36814
[Bug c++/36814] G++ won't warn about an uninitialized value
--- Comment #3 from jellegeerts at gmail dot com 2008-08-18 18:15 --- Created an attachment (id=16087) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16087&action=view) the `.ii' file that G++ created -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36814
[Bug c++/36814] G++ won't warn about an uninitialized value
--- Comment #4 from jellegeerts at gmail dot com 2008-08-18 18:16 --- Please see the attachments I created for more information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36814
[Bug c/45467] New: gcc won't warn about an uninitialized value
Hello,
I've compiled the following code using `gcc -std=c99 -O -g -Wall gcctest.c -o
gcctest':
<<<<<<<<<<<<<<<
#include
static int array[32];
#if 0 // If '#if 1' is used, GCC warns correctly about the use of uninitialized
variable 'i' below.
void foo(void);
void foo(void)
#else
static void foo(void)
#endif
{
for (int i; i < 32; ++i)
{
if (!array[i])
break;
}
}
int main(void)
{
foo();
return 0;
}
>>>>>>>>>>>>>>>
The problem is that GCC 4.5.1 does not warn about the use of the uninitialized
variable `i' on the line containing `if (!array[i])'. GCC 3.4.6 did this
correctly.
A perhaps interesting fact is that when the snippet is compiled with `#if 1'
instead of `#if 0', GCC 4.5.1 does warn correctly.
Thanks, Jelle
--
Summary: gcc won't warn about an uninitialized value
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jellegeerts at gmail dot com
GCC host triplet: mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #1 from jellegeerts at gmail dot com 2010-08-31 20:02 --- Created an attachment (id=21619) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21619&action=view) output of `gcc -v -save-temps -std=c99 -O -g -Wall gcctest.c -o gcctest' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #2 from jellegeerts at gmail dot com 2010-08-31 20:03 --- Created an attachment (id=21620) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21620&action=view) output of `gcc -v -save-temps -std=c99 -O -g -Wall gcctest.c -o gcctest' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #3 from jellegeerts at gmail dot com 2010-08-31 20:03 --- Created an attachment (id=21621) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21621&action=view) the `.i' file that GCC created -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #4 from jellegeerts at gmail dot com 2010-08-31 20:04 --- Created an attachment (id=21622) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21622&action=view) `.i' file that GCC created -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #6 from jellegeerts at gmail dot com 2010-08-31 20:14 --- It also happens in functions that do have side-effects. I can give you an example if you want? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45468] New: gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
When compiling a file with the `-Wuninitialized' flag, but without `-O', one
does not get a warning from GCC 4.5.1 (and `-Wuninitialized' has no effect).
GCC should output something like `cc1.exe: warning: -Wuninitialized is not
supported without -O', like GCC 3.4.5 did.
--
Summary: gcc does not warn about missing `-O' flag when
specifying `-Wuninitialized'
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jellegeerts at gmail dot com
GCC host triplet: mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #2 from jellegeerts at gmail dot com 2010-08-31 20:23 ---
I already reasoned that that might have been the case, but it seems false,
because if I compile the following snippet with GCC 4.5.1 with the command `gcc
newtest.c -std=c99 -Wall', I get no warning about the uninitialized use of the
`i' variable (only when I add `-O' I get the warning).
#include
int main(void)
{
for (int i; i < 32; ++i)
{
printf("%d\n", i);
}
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #3 from jellegeerts at gmail dot com 2010-08-31 20:24 --- Reopening bug. -- jellegeerts at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #7 from jellegeerts at gmail dot com 2010-08-31 20:32 ---
Updated code snippet, GCC doesn't warn here either if we leave `#if 0' as-is,
even though the function foo() may have side-effects.
<<<<<<<<<<<<<<<
#include
static int array[32];
#if 0 // If '#if 1' is used, GCC warns correctly about the use of uninitialized
variable 'i' below.
int foo(void);
int foo(void)
#else
static int foo(void)
#endif
{
for (int i; i < 32; ++i)
{
if (array[i])
return 1;
}
return 0;
}
int main(void)
{
foo();
return 0;
}
>>>>>>>>>>>>>>>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #5 from jellegeerts at gmail dot com 2010-08-31 20:36 ---
With `gcc -std=c99 -Wuninitialized -O0' I get no warning for the following code
snippet (I do with `-O1' though), so it still seems GCC 4.5.1 should warn about
`-O' not being specified.
<<<<<<<<<<<<<<<
#include
int main(void)
{
for (int i; i < 32; ++i)
{
printf("%d\n", i);
}
return 0;
}
>>>>>>>>>>>>>>>
--
jellegeerts at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #7 from jellegeerts at gmail dot com 2010-08-31 20:39 --- I am pointing out a case where it does not warn (and it seems to me that it should); what is your point? -- jellegeerts at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #9 from jellegeerts at gmail dot com 2010-08-31 20:45 --- I get that point, and I might open another bug report for that case, sure. Though, GCC does not warn about a missing `-O' (or `-Oxxx') flag, which was the point of this bug report. That the `-O0' flag doesn't work is another story. -- jellegeerts at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #9 from jellegeerts at gmail dot com 2010-08-31 20:47 --- Okay. :) Though, why does GCC warn when we have `#if 1', and not if we have `#if 0'? Just curiosity... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #10 from jellegeerts at gmail dot com 2010-08-31 20:49 --- Also, it seems a bit questionable to not warn when it is clearly(?) not the developers intent to use an uninitialized variable. What is the rationale behind this? Is it a pragmatic thing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45467] gcc won't warn about an uninitialized value
--- Comment #12 from jellegeerts at gmail dot com 2010-08-31 20:54 --- Thanks. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #12 from jellegeerts at gmail dot com 2010-08-31 20:59 --- Sorry Andrew, misinterpreted some things you said. I understand now that you meant that normally everything should work as expected. @Manuel, So, perhaps then this bug report is at least sort of valid? It seems that to get `-Wuninitialized' to *fully* work, one would need at least `-O1'? It seems to me, that if that is the case, and the user has not specified *any* `-O'-like option on the command-line, GCC should warn, since it's probably the user's intent to get a *fully* working `-Wuninitialized' option? If however, the user did specify `-O0', perhaps GCC should assume the user has knowledge about GCC not being able to warn about every case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #14 from jellegeerts at gmail dot com 2010-08-31 21:16 --- (In reply to comment #13) > (In reply to comment #12) > > @Manuel, > > So, perhaps then this bug report is at least sort of valid? It seems that to > > get `-Wuninitialized' to *fully* work, one would need at least `-O1'? > > No, higher levels of optimization may provide even better warnings (or disable > some false positives) Aye, I thought about that, but I didn't know enough about GCC and opted for making the question a bit simpler. I realize now that I shouldn't have, as this kind of sloppiness might spread misinformation. Sorry. > There is no such thing as a *fully* working Wuninitialized. The results > totally > depend on which optimization passes are run (and their order). See > http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings for more background on > the issues involved and existing bugs. :( It is an unfortunate truth that GCC's warnings are sometimes far from optimal, but maybe it's also good in some ways. For one thing, it forces us programmers to be more conscientious while coding. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- Comment #16 from jellegeerts at gmail dot com 2010-08-31 21:38 --- Thanks for the explanation. I understand it's a hard thing to fix. It's a bit of a sad situation, and has been for quite a while, unfortunately. :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
[Bug c++/36814] New: G++ won't warn about an uninitialized value
Hello,
I've compiled the code below using `g++ -Wuninitialized -O test.cc -o test':
<<<<<<<<<<<<<<<
bool cMyClass::Init()
{
bool retval;
if (some_function())
{
// If the `goto' is executed, 'return retval;' will use the
// uninitialized value of 'retval'.
goto error;
}
retval = true;
error:
return retval;
}
>>>>>>>>>>>>>>>
The problem is explained in the code comments above.
I think that GCC is supposed to warn about this, is that correct?
Thanks, Jelle
--
Summary: G++ won't warn about an uninitialized value
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jellegeerts at gmail dot com
GCC build triplet: i386-undermydesk-freebsd
GCC host triplet: i386-undermydesk-freebsd
GCC target triplet: i386-undermydesk-freebsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36814
