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

[Richard Biener <rguenther@suse.de>]

On Thu, 30 May 2019, Alex Henrie wrote:

> 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?

I think ms_hook_prologue should be allowed to apply to function types
and function decls.  If you say it should apply to function pointers
then I suppose you want to have it apply to the pointed to function
of the function pointer - but that's not possible without an indirection
via a function pointer typedef IIRC.

I also have the following which _may_ motivate that attributes
currently not applying to function types (because they only
affect function definitions) should also apply there:

typedef int  (myfun)  (int *) __attribute__((nonnull(1)));
myfun x;
int x(int *p) { return p != (int*)0; }

this applies nonnull to the function definition of 'x' but
I put the attribute on the typedef.  I didn't manage to
do without the myfun x; declaration.

> 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.

Sure.  Can you write down the three cases after macro expansion
here to clarify what you need?  Esp. say what the attribute should
apply to.  Just silencing the warning without actually achieving
what you want would be bad I think ;)

Richard.