http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52399
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |manu at gcc dot gnu.org
--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-02-27
14:03:06 UTC ---
(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.
