Created attachment 26761 [details] Invalid code $ gcc -flto -O -Wall -Wno-clobbered pr52399.c In file included from pr52399.c:3:0, from :6: pr52399.c: In function 'main': pr52399.c:8:7: warning: variable 'i' might be clobbered by 'longjmp' or 'vfork' [-Wclobbered]
Confirmed. This is because Wclobbered is a C family option but the warning is generated by middle-end code. lto1 would simply ignore -Wno-clobbered. -Wall is also a C family option and so ignored by lto1 btw. -Wall would need to be split up in parts for lto option processing.
(In reply to comment #1) > Confirmed. This is because Wclobbered is a C family option but the warning > is generated by middle-end code. lto1 would simply ignore -Wno-clobbered. > -Wall is also a C family option and so ignored by lto1 btw. -Wall would need > to be split up in parts for lto option processing. In this testcase, -Wall is a red-herring, it doesn't affect -Wclobbered. You get the same warning with: $ gcc -flto -O pr52399.c the reason is that -Wclobbered is initialized to -1, but only set to its default value in c_common_post_options, which I guess lto1 does not call. I guess the simplest fix is to make it a Common option and move the initialization to finish_options. I am not sure whether it is possible to make an option C/C++/LTO only. In an ideal world, GCC options would have some kind of namespace, so one could not use an option in the middle-end without specifying that it is handled by LTO. Ideally, GCC should also initialize options to their default value, instead of using the -1 trick to check whether the option was set by the user. I am not sure there is a mechanism yet to do this. This will have avoided this bug.
So the warning does not happen any more with -flto but does -W does not enable it either. c-family/c.opt has: Wclobbered C ObjC C++ ObjC++ Var(warn_clobbered) Warning EnabledBy(Wextra) Warn about variables that might be changed by \"longjmp\" or \"vfork\". Maybe this should move to common.opt like the other middle-end warnings.