Re: [warnings] attribs.c

[DJ Delorie <dj at redhat dot com>]

> Three tests is best;

Ok.

> I'd rather see more mandatory pedwarns (and probably some
> pedwarns-if-pedantic) turned into unconditional hard errors that GCC
> doesn't try to tolerate in order to simplify the possible range of
> trees for invalid programs for which GCC might try to generate code.
> I don't think adding tolerance of hard errors is generally
> desirable;

If they're truly hard errors, then we keep them.  I'm thinking of
errors that don't have to be fatal.  The only one I can think of off
the top of my head is "label at end of compound statement" or "label
at end of switch".  IMHO, that kind of error is more annoying than
useful, because the code is semantically clear but "the standard says
it's an error".  One of our customers has been complaining that
they're getting lots of "new" errors when they upgrade, and the
patches to disable those errors in gcc are trivial, "so why aren't
they just warnings?" they ask.

Another example: unrecognized attributes are warnings, but recognized
attributes with the wrong number of parameters are errors.  Why can't
they both be warnings, with different defaults for warnings-as-errors?

> (Allowing a per-warning flag for whether a warning is an error is however 
> desirable - we should get rid of the -Werror-implicit-function-declaration 
> special case in favour of such options in general.)

My thought was, for each -Wfoo (where we also have -Wno-foo) we
transparently support -Wfoo={warn,error,ignore,etc} and have the
diagnostic machinery automatically convert (or ignore) the diagnostic.
We could even extend common.opt to support an Error flag (or something
else) to set the defaults.

It only has to store a DK_* for each OPT_* and do a lookup when
warning() passes a matching OPT_*.