On Tue, May 28, 2019 at 1:05 PM Martin Sebor <mse...@gmail.com> wrote: > > On 5/24/19 9:49 AM, Alex Henrie wrote: > > Then is it preferable to simply silence Wattributes in this case? > > This case being PR86407? I'd say yes.
> 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. > > 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? > > 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? Those are very good points. The more information the optimizer has about how the function works, the better it can optimize the code near the function call. This would even apply to ms_hook_prologue because the optimizer should definitely not inline indirect calls to hookable functions even if it would inline a similar non-hookable function. At this point I think I'm convinced that any attribute that applies to a function should also be allowed on a function pointer without any warnings. We can start by turning off the warnings for the "fndecl" attributes and then clean up the other attributes as time goes on. Sound good? -Alex On Tue, May 28, 2019 at 1:05 PM Martin Sebor <mse...@gmail.com> 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. > > 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? > > 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
