This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [warnings] attribs.c
On Wed, 4 May 2005, DJ Delorie wrote:
> 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.
If there's a label at the end of a statement expression, does the label
count as a form of statement (making the statement expression have type
void) or are the type and value of the statement expression determined by
the expression before the label? If the latter, what if there's a jump to
that label within the statement expression? Was any of this ever really
documented?
> 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?
The case for unknown attributes as warnings is for compiling code using
new attributes with older versions that don't know those attributes. The
same may be the case for other warnings. I don't think there's a
well-thought-out distinction being made at present between where there
might be future extension of an attribute and where there won't be.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
joseph@codesourcery.com (CodeSourcery mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)