User account creation filtered due to spam.

Bug 23563

Summary: [4.0 Regression] False warning for uninitialized variable
Product: gcc Reporter: Jonathan Lennox <lennox>
Component: tree-optimizationAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: minor CC: gcc-bugs
Priority: P2 Keywords: diagnostic, missed-optimization
Version: 4.0.2   
Target Milestone: 4.1.0   
Host: Target:
Build: Known to work: 3.4.2 4.1.0 4.1.1 4.1.2
Known to fail: 4.0.0 Last reconfirmed: 2006-02-01 04:44:20
Bug Depends on:    
Bug Blocks: 24639    
Attachments: C++ source file that produces warning with GCC 4.0.2

Description Jonathan Lennox 2005-08-25 17:20:28 UTC
When I compile warn-thing.cpp (to be attached as soon as I've submitted this
bug) with gcc 4.0.2, I get the warning message

warn-thing.cpp:24: warning: 'variable' may be used uninitialized in this function

This warning appears to me to be incorrect, and did not occur with gcc 3.4.2.

The warning does not occur if optimization is not enabled.

The attached error output is from gcc version 4.0.2 20050728 (prerelease)
[FreeBSD] for i386-portbld-freebsd5.4, but I see the same results with gcc
version 4.0.2 20050806 (prerelease) (Debian 4.0.1-4) for i486-linux-gnu.

$ gcc40 -v -Wall -O2 -c warn-thing.cpp
Using built-in specs.
Target: i386-portbld-freebsd5.4
Configured with: ./..//gcc-4.0-20050728/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=40
--libdir=/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.0.2
--with-gxx-include-dir=/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.0.2/include/c++/
--with-gmp=/usr/local --disable-shared --prefix=/usr/local i386-portbld-freebsd5.4
Thread model: posix
gcc version 4.0.2 20050728 (prerelease) [FreeBSD]
 /usr/local/libexec/gcc/i386-portbld-freebsd5.4/4.0.2/cc1plus -quiet -v
warn-thing.cpp -quiet -dumpbase warn-thing.cpp -auxbase warn-thing -O2 -Wall
-version -o /var/tmp//ccjEgsIS.s
ignoring nonexistent directory
"/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.0.2/gcc/i386-portbld-freebsd5.4/4.0.2/../../../../i386-portbld-freebsd5.4/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/i386-portbld-freebsd5.4/4.0.2/include/c++/
 /usr/local/lib/gcc/i386-portbld-freebsd5.4/4.0.2/include/c++//i386-portbld-freebsd5.4
 /usr/local/lib/gcc/i386-portbld-freebsd5.4/4.0.2/include/c++//backward
 /usr/local/include
 /usr/local/lib/gcc/i386-portbld-freebsd5.4/4.0.2/gcc/i386-portbld-freebsd5.4/4.0.2/include
 /usr/include
End of search list.
GNU C++ version 4.0.2 20050728 (prerelease) [FreeBSD] (i386-portbld-freebsd5.4)
        compiled by GNU C version 4.0.2 20050728 (prerelease) [FreeBSD].
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129460
warn-thing.cpp: In function 'void foo()':
warn-thing.cpp:24: warning: 'variable' may be used uninitialized in this function
 as -o warn-thing.o /var/tmp//ccjEgsIS.s

For comparison, here is the non-warning output of gcc 3.4:

$ gcc -v -Wall -O2 -c warn-thing.cpp
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.2 [FreeBSD] 20040728
 /usr/libexec/cc1plus -quiet -v -D_LONGLONG warn-thing.cpp -quiet -dumpbase
warn-thing.cpp -auxbase warn-thing -O2 -Wall -version -o /var/tmp//ccHHC2rw.s
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/3.4
 /usr/include/c++/3.4/backward
 /usr/include
End of search list.
GNU C++ version 3.4.2 [FreeBSD] 20040728 (i386-fbsdproj-freebsd)
        compiled by GNU C version 3.4.2 [FreeBSD] 20040728.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 /usr/bin/as -v -o warn-thing.o /var/tmp//ccHHC2rw.s
GNU assembler version 2.15 [FreeBSD] 2004-05-23 (i386-obrien-freebsd) using BFD
version 2.15 [FreeBSD] 2004-05-23
Comment 1 Jonathan Lennox 2005-08-25 17:23:03 UTC
Created attachment 9585 [details]
C++ source file that produces warning with GCC 4.0.2

This file does not #include any files, so I'm providing the .cpp not the .ii. 
The preprocessed file is identical except for whitespace and
preprocessor-inserted line markers.
Comment 2 Andrew Pinski 2005-08-25 17:38:34 UTC
The issue here is due to exceptions.  On the mainline we don't warn but I think I can find a testcase 
where we do.
Comment 3 Andrew Pinski 2005-08-25 17:48:52 UTC
Well I right in saying this is due to exceptions but is wrong in saying I can reproduce this on the 
mainline.

It more has to do with not copying of the finally block (for the call of the deconstructor of stack_obj).

In 3.4.0 we copied the finally block in 4.0.2 we don't but in 4.1.0 we do again.

At -O2 we copy the finally block too.
Comment 4 Gabriel Dos Reis 2007-02-03 15:37:45 UTC
Fixed in GCC-4.1.0 and higher