[Bug lto/52399] With `-flto', `-Wno-clobbered' does not suppress the "might be clobbered" warning

["manu at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.