The attribute "unused" after a jump label is not understood by the C++ compiler. The following simple test program compiles fine with gcc, while g++ fails with error: int main() { unused_label: __attribute__((unused)) return 0; } Compiler versions tested: 2.95.3, 3.2.3, 3.3
I can confirm this. However, I did not find a place in the manual that states that it is allowed to use an attribute on a label (in particular, the idea of putting the attribute _after_ the colon seems exceedingly ugly to me). Can you point me to a relevant statement in the manual? If there is none, then this would be a bug in the C front end to grok such a thing. Thanks Wolfgang
From <http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html>: An attribute specifier list may appear __after__ the __colon__ following a label, other than a case or default label. The only attribute it makes sense to use after a label is unused. This feature is intended for code generated by programs which contains labels that may be unused but which is compiled with -Wall. It would not normally be appropriate to use in it human-written code, though it could be useful in cases where the code that jumps to the label is contained within an #ifdef conditional. Also from that page: Because of infelicities in the grammar for attributes, some forms described here may not be successfully parsed in all cases I do not know if this should be acceptable in c++.
Thanks Andrew. My personal opinion is that the association of language lawyers should throughly enjail the person who invented this syntax, and should bar him from ever again designing language extensions. Oh well... W.
label: __attribute__ ((whatever)) cannot be well formed g++, because, this is allowed __attribute__ ((unused)) int i; and so is label: int i; so what does label: __attribute__ ((unused)) int i; mean?
It's a feature! 2003-07-25 Nathan Sidwell <nathan@codesourcery.com> * doc/extend.texi (Function Attributes): GNU C++ does now allow unused parameter decls. (Attribute Syntax): GNU C++ does not allow label attributes to be after the ':'.
*** Bug 14273 has been marked as a duplicate of this bug. ***