Bug 31707 - Spurious "'<variable>' may be used uninitialized in this function" warnings when using __builtin_setjmp and loops and extern function call
Spurious "'<variable>' may be used uninitialized in this function" warnings w...
Status: RESOLVED WONTFIX
Product: gcc
Classification: Unclassified
Component: middle-end
4.2.0
: P3 enhancement
: ---
Assigned To: Not yet assigned to anyone
: diagnostic
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
 
Reported: 2007-04-25 23:27 UTC by KJK::Hyperion
Modified: 2009-11-10 09:00 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-05-26 18:30:35


Attachments
Preprocessor output (5.31 KB, text/plain)
2007-04-25 23:28 UTC, KJK::Hyperion
Details
GIMPLE source for the test case (2.91 KB, text/plain)
2007-04-25 23:29 UTC, KJK::Hyperion
Details
Final tree dump for the test case (1.73 KB, text/plain)
2007-04-25 23:30 UTC, KJK::Hyperion
Details

Note You need to log in before you can comment on or make changes to this bug.
Description KJK::Hyperion 2007-04-25 23:27:17 UTC
Command line: gcc -c lib\rtl\workitem.c -o obj-i386\lib\rtl\workitem.o -Iobj-i386\lib\rtl -Ilib\rtl -D__USE_W32API -D_NTOSKRNL_ -D__NO_CTYPE_INLINES -DNO_RTL_INLINES -D_NTSYSTEM_ -D_NTDLLBUILD_ -Iobj-i386\lib\rtl -I. -Iinclude -Iinclude\psdk -Iinclude\crt -Iinclude\ddk -Iinclude\GL -Iinclude\ndk -Iinclude\reactos -Iinclude\reactos\libs -D_M_IX86 -D_X86_ -D__i386__ -D_REACTOS_ -DDBG -D_SEH_ENABLE_TRACE -Wall -march=pentium -Wpointer-arith -Os -Wno-strict-aliasing -ftracer -momit-leaf-frame-pointer -mpreferred-stack-boundary=2 -g -pipe -Werror -fno-optimize-sibling-calls -save-temps -v

Output:
gcc: warning: -pipe ignored because -save-temps specified
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.2.0/configure --host=mingw32 --target=mingw32 --prefix=/mingw --with-gnu-as --with-gnu-ld --enable-threads --disable-nls --enable-languages=c,c++ --enable-threads=win32 --disable-win32-registry --disable-win32-registry --disable-shared
Thread model: win32
gcc version 4.2.0 20070415 (prerelease)
 d:/rosbe/4.2.0/bin/../libexec/gcc/mingw32/4.2.0/cc1.exe -E -quiet -v -Iobj-i386\lib\rtl -Ilib\rtl -Iobj-i386\lib\rtl -I. -Iinclude -Iinclude\psdk -Iinclude\crt -Iinclude\ddk -Iinclude\GL -Iinclude\ndk -Iinclude\reactos -Iinclude\reactos\libs -iprefix d:\rosbe\4.2.0\bin\../lib/gcc/mingw32/4.2.0/ -D__USE_W32API -D_NTOSKRNL_ -D__NO_CTYPE_INLINES -DNO_RTL_INLINES -D_NTSYSTEM_ -D_NTDLLBUILD_ -D_M_IX86 -D_X86_ -D__i386__ -D_REACTOS_ -DDBG -D_SEH_ENABLE_TRACE lib\rtl\workitem.c -march=pentium -momit-leaf-frame-pointer -mpreferred-stack-boundary=2 -Wall -Wpointer-arith -Wno-strict-aliasing -Werror -ftracer -fno-optimize-sibling-calls -fworking-directory -Os -fpch-preprocess -o workitem.i
ignoring nonexistent directory "c:/mingw/include"
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "c:/mingw/lib/gcc/mingw32/4.2.0/include"
ignoring nonexistent directory "c:/mingw/mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 obj-i386/lib/rtl
 lib/rtl
 obj-i386/lib/rtl
 .
 include
 include/psdk
 include/crt
 include/ddk
 include/GL
 include/ndk
 include/reactos
 include/reactos/libs
 D:/RosBE/4.2.0/include
 D:/RosBE/4.2.0/lib/gcc/mingw32/4.2.0/include
 d:/rosbe/4.2.0/bin/../lib/gcc/mingw32/4.2.0/include
End of search list.
 d:/rosbe/4.2.0/bin/../libexec/gcc/mingw32/4.2.0/cc1.exe -fpreprocessed workitem.i -quiet -dumpbase workitem.c -march=pentium -momit-leaf-frame-pointer -mpreferred-stack-boundary=2 -auxbase-strip obj-i386\lib\rtl\workitem.o -g -Os -Wall -Wpointer-arith -Wno-strict-aliasing -Werror -version -ftracer -fno-optimize-sibling-calls -o workitem.s
GNU C version 4.2.0 20070415 (prerelease) (mingw32)
        compiled by GNU C version 4.2.0 20070415 (prerelease).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=131002
Compiler executable checksum: 232281512bb28abd92c2d204d6f594e1
cc1.exe: warnings being treated as errors
lib\rtl\workitem.c: In function 'foo':
lib\rtl\workitem.c:21: warning: '_SEHPortableFrame' may be used uninitialized in this function
lib\rtl\workitem.c:21: warning: '_SEHState' may be used uninitialized in this function
Comment 1 KJK::Hyperion 2007-04-25 23:28:12 UTC
Created attachment 13442 [details]
Preprocessor output
Comment 2 KJK::Hyperion 2007-04-25 23:29:44 UTC
Created attachment 13443 [details]
GIMPLE source for the test case
Comment 3 KJK::Hyperion 2007-04-25 23:30:33 UTC
Created attachment 13444 [details]
Final tree dump for the test case

By going through the tree dump, it appears the warning has no reason to be
Comment 4 KJK::Hyperion 2007-04-25 23:33:49 UTC
A couple more notes:
 * no warning if setjmp is used instead of __builtin_setjmp
 * no warning if the call to "bar()" is removed
 * no warning in GCC 4.1.2
Comment 5 Andrew Pinski 2007-04-25 23:59:25 UTC
The problem is that the CFG does not know that the first time through the loop when calling bar, you cannot get to the setjmp.  This is a hard problem to solve really.  You have to track the uninitialized variable usage your solve to solve it correctly.
Comment 6 Andrew Pinski 2008-05-26 11:57:18 UTC
As mentioned this is a very hard problem to solve.  The compiler has to track all uses of __builtin_setjmp and __builtin_longjmp but of which are really only used for Ada eh usage really.  So using it inside code which is not Ada code what do you expect?  Look at how the CFG is created and you will notice it is a hard problem to solve.
Comment 7 KJK::Hyperion 2008-05-26 14:17:06 UTC
(In reply to comment #6)
> but of which are really only used for Ada eh usage really.

and C++ for SJLJ exceptions. No? The library I use it in is a custom exception handling library, that integrates with the Windows exception handling ABI in a way that GCC can't (yet). As unfortunate artifacts of user-visible syntax, the code is full of hacks - local variables I expect to be const-folded or otherwise inlined, bogus loops, bogus conditionals. GCC always had difficulty with it, producing code like "set register to 1; if register equals 1 then...", but GCC 4.2 is the first release that actually hurts our build with spurious warnings

From tree dumps and disassemblies I can see a significant change in how __builtin_setjmp is emitted between 4.1 and 4.2, and that's all I know about it. I have no real interest in GCC internals

Can this issue at least be confirmed as NEW, though? or I'm afraid it will never even get a chance to be looked at by someone else
Comment 8 Andrew Pinski 2008-05-26 16:24:15 UTC
(In reply to comment #7)
> and C++ for SJLJ exceptions. No?

Nope, normal builtin exception for sjlj is expanded later on and does not go through the __builtin_setjmp/__builtin_longjmp mechanism at all.  In fact it is expanded late in the phase after the tree level has finished.
Comment 9 Eric Botcazou 2008-05-26 18:30:35 UTC
> and C++ for SJLJ exceptions. No?

No, regular SJLJ exceptions are implemented in a more clever way and don't
suffer from this problem.

> GCC always had difficulty with it, producing code like "set register to 1;
> if register equals 1 then...", but GCC 4.2 is the first release that
> actually hurts our build with spurious warnings

GCC 4.0.x and 4.1.x will misoptimize this kind of code, GCC 4.2+ is OK.

> From tree dumps and disassemblies I can see a significant change in how
> __builtin_setjmp is emitted between 4.1 and 4.2, and that's all I know
> about it.

Right, __builtin_setjmp support was overhauled for 4.2.

> Can this issue at least be confirmed as NEW, though? or I'm afraid it will
> never even get a chance to be looked at by someone else

Yes, I'm going to confirm, but this is not (realistically) fixable.
Comment 10 Manuel López-Ibáñez 2009-08-05 16:01:54 UTC
I think we should close this as WONTFIX.

* In GCC 4.5 we only warn at -O1 with a "may be", no warning with -O{0,2,3,s}. So it seems just a matter of optimizers exposing/hiding things.

* The testcase is a bit obscure, and too large for my taste.

* Two developers have said that this is not realistically fixable.

* The impact on users seems to be limited.
Comment 11 Eric Botcazou 2009-11-10 09:00:29 UTC
Not realistically fixable.