Re: [PATCH] PR c/86407 - Add option to ignore fndecl attributes on function pointers

[Martin Sebor <msebor@gmail.com>]

On 5/24/19 9:49 AM, Alex Henrie wrote:
> On Fri, May 24, 2019 at 2:01 AM Richard Biener <rguenther@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 <msebor@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 <rguenther@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 <msebor@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 <msebor@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