This is the mail archive of the gcc-patches@gcc.gnu.org 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


DJ Delorie wrote:
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.

I'm OK with an internal-only OPT_* value, but I can't think of a way to stop developers from using it only because they're too lazy to think about which other OPT_* values might be appropriate.

I don't object to an internal-only OPT_ value.


What I'm less keen on is a new command-line -Wno-options switch. I've never seen that in any other compiler. We'd have to decide whether -Wno-options applies to warnings that would be issued based on options preceding -Wno-options. It just seems needless to me...

In general, I agree, BUT... it's a warning because gcc knows that it
might be intentional.

There are at least two categories: (1) warnings about options that are no longer supported, and (2) warnings about surprising usage or combinations of options.


(I think (1) ought to be an error, not a warning, in any case where the option would affect code-generation. I see that -fvolatile is an error, which is great. I'm not actually aware of any examples of options that affect code-generation that we presently just warn about; maybe there aren't any, which would make me happy.)

I guess I'm just unsympathetic to people who need to adjust their build systems for different compilers. I've worked a lot on build systems for cross-platform development (outside of just GCC), and I've universally found that I had to have a build system that could use different compiler flags in different places. In other words, even if I had -Wno-options -- and old compilers that don't support it silently ignored it, which I'm not sure they will, in which case it doesn't help at all with using old compilers and new compilers side-by-side -- I still need build-system configury from system to system. So, I don't think -Wno-options is going to really solve very many people's problems, even though it may be just what your customer wants.

However, I'm not going to fight very hard about it. I've said my piece.

Thanks,

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


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