[warnings] tagging warnings about options themselves

[Mark Mitchell]

> 1. If we can get to the point where every warning() call has an OPT_*,
>    then we can change warning() to *require* an OPT_* and then we've
>    locked in the new system - nobody could then add new warnings
>    without being able to control them.  I was pondering a catch-all
>    option to avoid an explosion of options, messy but effective.

This is an internal issue, affecting us as developers; it's not an 
argument for changing the external interface of the compiler by adding a 
  new -Woption.

> 2. We had a customer complain about it just today, which is why I
>    looked into it.  Their policy is to use -Werror (I've seen that a
>    lot) which means that *every* uncontrollable warning is going to
>    stop their build cold.  Yes, they could (and did) change their
>    build to avoid the warnings, but if we're going to (1) provide
>    -Werror and also (2) add new warnings all over the place, we should
>    take into account the problems that's going to cause.

I know all about such customers. :-)

However, I think that it's a mistake to allow these option warnings to 
be disregarded.  First, they have to provide the -Wno-options option 
somewhere, which means that one of the compilers in the hypothetical 
build system that uses the same options with all compilers may warn 
about it.  Second, some of these warnings (-fvolatile is no longer 
supported, for example) are warnings that should stop a -Werror build 
cold.  If you're using -fvolatile and upgrade to a compiler that doesn't 
have it, you want to know that you have to go change all of your code.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304