On 10/15/18 9:21 AM, Nikolai Merinov wrote: > Hi Martin, > > On 10/15/18 6:20 PM, Martin Sebor wrote: >> On 10/15/2018 01:55 AM, Nikolai Merinov wrote: >>> Hi Martin, >>> >>> On 10/12/18 9:58 PM, Martin Sebor wrote: >>>> On 10/12/2018 04:14 AM, Nikolai Merinov wrote: >>>>> Hello, >>>>> >>>>> In https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01795.html mail I >>>>> suggested patch to have ability to control behavior of >>>>> "__attribute__((warning))" in case when option "-Werror" enabled. >>>>> Usage >>>>> example: >>>>> >>>>>> #include <string.h> >>>>>> int a() __attribute__((warning("Warning: `a' was used"))); >>>>>> int a() { return 1; } >>>>>> int main () { return a(); } >>>>> >>>>>> $ gcc -Werror test.c >>>>>> test.c: In function ‘main’: >>>>>> test.c:4:22: error: call to ‘a’ declared with attribute warning: >>>>>> Warning: `a' was used [-Werror] >>>>>> int main () { return a(); } >>>>>> ^ >>>>>> cc1: all warnings being treated as errors >>>>>> $ gcc -Werror -Wno-error=warning-attribute test.c >>>>>> test.c: In function ‘main’: >>>>>> test.c:4:22: warning: call to ‘a’ declared with attribute warning: >>>>>> Warning: `a' was used >>>>>> int main () { return a(); } >>>>>> ^ >>>>> Can you provide any feedback on suggested changes? >>>> >>>> It seems like a useful feature and in line with the philosophy >>>> that distinct warnings should be controlled by their own options. >>>> >>>> I would only suggest to consider changing the name to >>>> -Wattribute-warning, because it applies specifically to that >>>> attribute (as opposed to warnings about attributes in general). >>>> >>>> There are many attributes in GCC and diagnosing problems that >>>> are unique to each, under the same -Wattributes option, is >>>> becoming too coarse and overly limiting. To make it more >>>> flexible, I expect new options will need to be introduced, >>>> such as -Wattribute-alias (to control aspects of the alias >>>> attribute and others related to it), or -Wattribute-const >>>> (to control diagnostics about functions declared with >>>> attribute const that violate the attribute's constraints). >>>> >>>> An alternative might be to introduce a single -Wattribute= >>>> <attribute-list> option where the <attribute-list> gives >>>> the names of all the distinct attributes whose unique >>>> diagnostics one might need to control. >>>> >>>> Martin >>> >>> Currently there is several styles already in use: >>> >>> -Wattribute-alias where "attribute" word used as prefix for name of >>> attribute, >>> -Wsuggest-attribute=[pure|const|noreturn|format|malloc] where name of >>> attribute passed as possible argument, >>> -Wmissing-format-attribute where "attribute" word used as suffix, >>> -Wdeprecated-declarations where "attribute" word not used at all even >>> if this warning option was created especially for "deprecated" >>> attribute. >>> >>> I changed name to "-Wattribute-warning" as you suggested, but >>> unifying style for all attribute related warning looks like separate >>> activity. Please check new patch in attachments. >>> >> >> Thanks for survey! I agree that making the existing options >> consistent (if that's what we want) should be done separately. >> >> Martin >> >> PS It doesn't look like your latest attachments made it to >> the list. >> > Thank you for mentioning. There was my mistake. Now it's attached >> >>> Updated changelog: >>> >>> gcc/Changelog >>> >>> 2018-10-14 Nikolai Merinov <n.meri...@inango-systems.com> >>> >>> * gcc/common.opt: Add -Wattribute-warning. >>> * gcc/doc/invoke.texi: Add documentation for >>> -Wno-attribute-warning. >>> * gcc/testsuite/gcc.dg/Wno-attribute-warning.c: New test. >>> * gcc/expr.c (expand_expr_real_1): Add new attribute to >>> warning_at >>> call to allow user configure behavior of "warning" attribute I split up the ChangeLog and fixed a very minor whitespace issue in the docs and installed the patch.
I went round and round over whether or not to change the doc text. It discusses the attribute and the warning and it's easy to mix up the two. But ultimately I decided not to change it. Thanks and sorry for the long delays. Jeff >
