User account creation filtered due to spam.
Created attachment 28180 [details]
generates incorrect diagnostics with gcc -O2 -Wclobbered
If I compile the attached program via the command "gcc -S -Wclobbered
-O2 w.i" (GCC 4.7.1, x86-64, Fedora 17), the output is:
w.i: In function 'png_load_body':
w.i:37:13: warning: variable 'info_ptr' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered]
w.i:38:9: warning: variable 'fp' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered]
Both warnings are incorrect, because info_ptr and fp are not live
across any possible longjmp. If longjmp munges these variables,
setjmp must return a nonzero value, and no uses of these variables are
reachable in that case.
Like Bug#48968, I ran into this problem when building Emacs. This test
case is much shorter, though (I whittled it down), so it should be
easier to debug.
Both info_ptr and fp are alive across the setjmp. GCC does not do fancy detection of alive on one of branches of the result of setjmp. It just warns if it is alive across on either branch on setjmp.
> GCC ... warns if it is alive across on either branch on setjmp.
OK, thanks, that's the bug then. GCC should warn only about the
longjmp branch, not about the non-lonjmp branch.
Can GCC model the longjmp branch as assigning garbage to all the
nonvolatile locals, and then use the algorithm it's already using
when it warns about use of uninitialized locals? Something like
that should do the trick.
I have more issues with Gcc generating wrong warning.
When trying to compile new dissectors with gcc 4.8.8 in wireshark I got:
/home/mat/workspace/wireshark/epan/dissectors/packet-dcerpc-dnsserver.c: In function ‘dnsserver_dissect_struct_DNS_RPC_NAME_LIST’:
/home/mat/workspace/wireshark/epan/dissectors/packet-dcerpc-dnsserver.c:1902:23: warning: variable ‘tmptree’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
volatile proto_tree *tmptree = NULL;
/home/mat/workspace/wireshark/epan/dissectors/packet-dcerpc-dnsserver.c:1903:23: warning: variable ‘tmpitem’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
volatile proto_item *tmpitem = NULL;
The manpage of longjmp states that
"The values of automatic variables are unspecified after a call to longjmp() if they meet all the following criteria:
· they are local to the function that made the corresponding setjmp(3) call;
· their values are changed between the calls to setjmp(3) and longjmp(); and
· they are not declared as volatile."
So without the volatile keyword the warning would valid but I explicitly specified volatile to avoid this warning, unless I mis-understood something I think this warning shouldn't be emitted.
(In reply to Matthieu Patou from comment #3)
> volatile proto_tree *tmptree = NULL;
proto_tree * volatile tmptree = NULL;
It's the variable itself that needs to be volatile, not the memory it points to.