public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/38961] New: if () block not true but a command in it is still in effect
@ 2009-01-24 17:36 jellegeerts at gmail dot com
2009-01-24 17:48 ` [Bug c/38961] " falk at debian dot org
` (9 more replies)
0 siblings, 10 replies; 12+ messages in thread
From: jellegeerts at gmail dot com @ 2009-01-24 17:36 UTC (permalink / raw)
To: gcc-bugs
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 <stdio.h>
#include <string.h>
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/38961] if () block not true but a command in it is still in effect
2009-01-24 17:36 [Bug c/38961] New: if () block not true but a command in it is still in effect jellegeerts at gmail dot com
@ 2009-01-24 17:48 ` falk at debian dot org
2009-01-24 18:15 ` jellegeerts at gmail dot com
` (8 subsequent siblings)
9 siblings, 0 replies; 12+ messages in thread
From: falk at debian dot org @ 2009-01-24 17:48 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from falk at debian dot org 2009-01-24 17:48 -------
const char *logout_cmd = logout_cmd;
actually initializes the variable with its own (uninitialized) value.
You can get a warning about this with "-Winit-self".
--
falk at debian dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/38961] if () block not true but a command in it is still in effect
2009-01-24 17:36 [Bug c/38961] New: if () block not true but a command in it is still in effect jellegeerts at gmail dot com
2009-01-24 17:48 ` [Bug c/38961] " falk at debian dot org
@ 2009-01-24 18:15 ` jellegeerts at gmail dot com
2009-01-24 18:19 ` rguenth at gcc dot gnu dot org
` (7 subsequent siblings)
9 siblings, 0 replies; 12+ messages in thread
From: jellegeerts at gmail dot com @ 2009-01-24 18:15 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/38961] if () block not true but a command in it is still in effect
2009-01-24 17:36 [Bug c/38961] New: if () block not true but a command in it is still in effect jellegeerts at gmail dot com
2009-01-24 17:48 ` [Bug c/38961] " falk at debian dot org
2009-01-24 18:15 ` jellegeerts at gmail dot com
@ 2009-01-24 18:19 ` rguenth at gcc dot gnu dot org
2009-01-24 18:45 ` jellegeerts at gmail dot com
` (6 subsequent siblings)
9 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-01-24 18:19 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-24 18:19 -------
You are invoking undefined behavior so anything can happen.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/38961] if () block not true but a command in it is still in effect
2009-01-24 17:36 [Bug c/38961] New: if () block not true but a command in it is still in effect jellegeerts at gmail dot com
` (2 preceding siblings ...)
2009-01-24 18:19 ` rguenth at gcc dot gnu dot org
@ 2009-01-24 18:45 ` jellegeerts at gmail dot com
2009-01-24 19:37 ` rguenth at gcc dot gnu dot org
` (5 subsequent siblings)
9 siblings, 0 replies; 12+ messages in thread
From: jellegeerts at gmail dot com @ 2009-01-24 18:45 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/38961] if () block not true but a command in it is still in effect
2009-01-24 17:36 [Bug c/38961] New: if () block not true but a command in it is still in effect jellegeerts at gmail dot com
` (3 preceding siblings ...)
2009-01-24 18:45 ` jellegeerts at gmail dot com
@ 2009-01-24 19:37 ` rguenth at gcc dot gnu dot org
2009-01-24 22:25 ` jellegeerts at gmail dot com
` (4 subsequent siblings)
9 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-01-24 19:37 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-24 19:37 -------
The program is only undefined at runtime, we may not reject the program at
compile-time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/38961] if () block not true but a command in it is still in effect
2009-01-24 17:36 [Bug c/38961] New: if () block not true but a command in it is still in effect jellegeerts at gmail dot com
` (4 preceding siblings ...)
2009-01-24 19:37 ` rguenth at gcc dot gnu dot org
@ 2009-01-24 22:25 ` jellegeerts at gmail dot com
2009-01-24 22:33 ` Andrew Thomas Pinski
2009-01-24 22:33 ` pinskia at gmail dot com
` (3 subsequent siblings)
9 siblings, 1 reply; 12+ messages in thread
From: jellegeerts at gmail dot com @ 2009-01-24 22:25 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bug c/38961] if () block not true but a command in it is still in effect
2009-01-24 22:25 ` jellegeerts at gmail dot com
@ 2009-01-24 22:33 ` Andrew Thomas Pinski
0 siblings, 0 replies; 12+ messages in thread
From: Andrew Thomas Pinski @ 2009-01-24 22:33 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
Sent from my iPhone
On Jan 24, 2009, at 2:24 PM, "jellegeerts at gmail dot com" <gcc-bugzilla@gcc.gnu.org
> wrote:
>
>
> ------- 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.
Except -Winit-self is there because we decided a long time ago initing
the variable by itself is a way to disable the uninitization warning.
In fact before 3.4 there was no way to get this warning (oh I added
this option:) ).
Thanks,
Andrew Pinsky
>
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/38961] if () block not true but a command in it is still in effect
2009-01-24 17:36 [Bug c/38961] New: if () block not true but a command in it is still in effect jellegeerts at gmail dot com
` (5 preceding siblings ...)
2009-01-24 22:25 ` jellegeerts at gmail dot com
@ 2009-01-24 22:33 ` pinskia at gmail dot com
2009-01-25 1:50 ` jellegeerts at gmail dot com
` (2 subsequent siblings)
9 siblings, 0 replies; 12+ messages in thread
From: pinskia at gmail dot com @ 2009-01-24 22:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from pinskia at gmail dot com 2009-01-24 22:33 -------
Subject: Re: if () block not true but a command in it is still in effect
Sent from my iPhone
On Jan 24, 2009, at 2:24 PM, "jellegeerts at gmail dot com"
<gcc-bugzilla@gcc.gnu.org
> wrote:
>
>
> ------- 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.
Except -Winit-self is there because we decided a long time ago initing
the variable by itself is a way to disable the uninitization warning.
In fact before 3.4 there was no way to get this warning (oh I added
this option:) ).
Thanks,
Andrew Pinsky
>
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/38961] if () block not true but a command in it is still in effect
2009-01-24 17:36 [Bug c/38961] New: if () block not true but a command in it is still in effect jellegeerts at gmail dot com
` (6 preceding siblings ...)
2009-01-24 22:33 ` pinskia at gmail dot com
@ 2009-01-25 1:50 ` jellegeerts at gmail dot com
2009-01-25 1:54 ` jellegeerts at gmail dot com
2009-01-25 11:15 ` rguenth at gcc dot gnu dot org
9 siblings, 0 replies; 12+ messages in thread
From: jellegeerts at gmail dot com @ 2009-01-25 1:50 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/38961] if () block not true but a command in it is still in effect
2009-01-24 17:36 [Bug c/38961] New: if () block not true but a command in it is still in effect jellegeerts at gmail dot com
` (7 preceding siblings ...)
2009-01-25 1:50 ` jellegeerts at gmail dot com
@ 2009-01-25 1:54 ` jellegeerts at gmail dot com
2009-01-25 11:15 ` rguenth at gcc dot gnu dot org
9 siblings, 0 replies; 12+ messages in thread
From: jellegeerts at gmail dot com @ 2009-01-25 1:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c/38961] if () block not true but a command in it is still in effect
2009-01-24 17:36 [Bug c/38961] New: if () block not true but a command in it is still in effect jellegeerts at gmail dot com
` (8 preceding siblings ...)
2009-01-25 1:54 ` jellegeerts at gmail dot com
@ 2009-01-25 11:15 ` rguenth at gcc dot gnu dot org
9 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-01-25 11:15 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from rguenth at gcc dot gnu dot org 2009-01-25 11:15 -------
The self-init is of course for the case where the -Wuninitialized warning is
bogus (which happens). It simply has no effect on whatever undefinedness
is in your code - it was added to be a "cheaper" way instead of adding the
usual zero-initialization which people do when they get seemingly bogus
uninitialized warnings.
Yes, I see the situation is somewhat unfortunate here ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38961
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-01-25 11:15 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-01-24 17:36 [Bug c/38961] New: if () block not true but a command in it is still in effect jellegeerts at gmail dot com
2009-01-24 17:48 ` [Bug c/38961] " falk at debian dot org
2009-01-24 18:15 ` jellegeerts at gmail dot com
2009-01-24 18:19 ` rguenth at gcc dot gnu dot org
2009-01-24 18:45 ` jellegeerts at gmail dot com
2009-01-24 19:37 ` rguenth at gcc dot gnu dot org
2009-01-24 22:25 ` jellegeerts at gmail dot com
2009-01-24 22:33 ` Andrew Thomas Pinski
2009-01-24 22:33 ` pinskia at gmail dot com
2009-01-25 1:50 ` jellegeerts at gmail dot com
2009-01-25 1:54 ` jellegeerts at gmail dot com
2009-01-25 11:15 ` rguenth at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).