On Tue, 28 May 2019, Martin Sebor wrote: > On 5/24/19 9:49 AM, Alex Henrie wrote: > > On Fri, May 24, 2019 at 2:01 AM Richard Biener <rguent...@suse.de> wrote: > > > > > > I'm not sure we really need a new warning for this. > > > > On Fri, May 24, 2019 at 9:23 AM Martin Sebor <mse...@gmail.com> wrote: > > > > > > I don't think GCC makes a formal distinction between function > > > attributes that affect only function definitions vs those that > > > affect its users, or both. It might be a useful distinction > > > to introduce, perhaps even for functions as well as variables, > > > but as it is, users (as well as GCC developers) are on our own > > > to figure it out. > > > > Then is it preferable to simply silence Wattributes in this case? > > This case being PR86407? I'd say yes. I think one general problem > to solve is the missing suppression for typedefs. This could be > useful for other warnings as well. Another is providing a knob to > control the warning when one kind of an attribute is used with > an entity of a different kind (function vs type, or variable vs > type). Yet another might be to control warnings for individual > attributes. > > > > > On Fri, May 24, 2019 at 2:01 AM Richard Biener <rguent...@suse.de> wrote: > > > > > > > +int __attribute__((__ms_hook_prologue__)) func(); /* no warnings */ > > > > + > > > > > > But this is a declaration? > > > > On Fri, May 24, 2019 at 9:23 AM Martin Sebor <mse...@gmail.com> wrote: > > > > > > My first question is: what is the meaning of "function definition > > > attributes?" Presumably those that affect only the definition of > > > a function and not its callers or other users? > > > > As far as I can tell, "fndecl" is a misnomer: these attributes are > > more accurately called "function definition attributes", i.e. > > attributes that affect the assembly code of the function but do not > > affect its calling convention. > > That's one possible definition but there are examples that don't > fit it (at least not very neatly). > > Attribute malloc attaches only to fndecl and not its type but > doesn't affect the code for a function definition. FWIW, I > think this is just a bug -- attribute malloc should apply > to a function type for the same reason the closely related > attribute alloc_size does.
Yeah, we have existing attributes that do not apply well to indirect calls due to mistakes made in the past. Of course for things like 'malloc' this isn't a correctness issue. > Attribute constructor also attaches to a fndecl even though it > doesn't affect the function's codegen but that of its caller > (the runtime). In this case, though, I'd say that's fine. > Should it be classified as a function definition attribute? I think the issue is that internally we know what a fndecl is but that doesn't match what the C standard says is a function declaration. So it's important to not mix terms for GCC internals and terms used in diagnostics which generally should use terms from the language standard. > Attributes cold and hot also apply to a fndecl and not its type > but they affect both the function's definition and its callers. > I think this also makes sense. Should they be classified as > function definition attributes? > > > On Fri, May 24, 2019 at 9:23 AM Martin Sebor <mse...@gmail.com> wrote: > > > > > > Finally, with this as a prerequisite, if we decided that a warning > > > like this would be useful, tests to verify that it works for all > > > the definition attributes and not for the rest would need to be > > > added (i.e., in addition to ms_hook_prologue). > > > > Okay, I will add tests for the other function attributes that should > > behave in the same way, commenting out the tests that will require > > more work to pass. > > > > The end goal is to include __ms_hook_prologue__ in the WINAPI macro on > > Wine without causing spurious warnings. This will go a long way > > towards making Wine compatible with current and future Windows > > programs. Thank you for help. > > Yes, I understand the goal. I'm not sure that the proposed change > is the right way to do it. It seems to me that a more targeted bug > to fix with the broadest benefit is that _Pragma GCC diagnostic (or > some such mechanism) cannot be used to suppress the warning for > typedefs. > > Martin > -- Richard Biener <rguent...@suse.de> SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)
