This is the mail archive of the
mailing list for the GCC project.
Re: [warnings] tagging warnings about options themselves
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
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.