This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 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
(916) 791-8304

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]