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

[Alex Henrie <alexhenrie24@gmail.com>]

On Thu, May 30, 2019 at 6:59 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 30 May 2019, Alex Henrie wrote:
>
> > 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.
>
> This is inherently a property of the attribute in question.  The issue is
> not whether it applies to function pointers; it's whether it applies to
> function types.
>
> For example, the "section" or "alias" attributes are attributes that apply
> to a declaration, but not a type.  Because they apply to variables as well
> as functions, they are meaningful on function pointers - but the meaning
> is *not* the same as applying them to the pointed-to function.
>
> The "flatten" attribute, however, seems only meaningful for functions, not
> variables, not function types and not function pointers.
>
> We should try to work out for each attribute exactly what construct it
> appertains to - which for many but not all function attributes is indeed
> the type of the function rather than the function itself.  Then move to
> making such attributes work on types.  But for attributes such as
> "flatten" that logically appertain to the declaration not its type, we
> should continue to diagnose them on function pointers or types.

In Wine we need a way to (without warnings) put ms_hook_prologue into
a macro that is applied to functions, function pointers, and function
pointer typedefs. It sounds like you're saying that you will not
accept a patch that silences or splits off warnings about using
ms_hook_prologue with function pointers and function pointer typedefs.
So how do you think Wine's problem should be solved?

It seems to me that any information about the target of a function
pointer, even the flatten attribute or the ms_hook_prologue attribute,
provides information that could be useful for optimizing the code
around the indirect function call. That sounds like a compelling
argument for allowing these attributes in more places without
warnings.

-Alex