On Fri, 31 May 2019, Alex Henrie wrote:
> On Fri, May 31, 2019 at 1:38 AM Richard Biener <rguent...@suse.de> wrote:
> >
> > On Thu, 30 May 2019, Alex Henrie wrote:
> >
> > > 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.
>
> No, if ms_hook_prologue is applied to a function pointer, it shouldn't
> do anything except maybe trigger some optimization of the code around
> the indirect function call.
>
> > 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.
>
> That is a great example and another compelling reason to allow
> "fndecl" attributes in more places.
>
> > > 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 ;)
>
> Essentially, the following needs to compile without warnings:
>
> #define WINAPI __attribute__((__stdcall__)) \
> __attribute__((__ms_hook_prologue__))
>
> typedef unsigned int (WINAPI *APPLICATION_RECOVERY_CALLBACK)(void*);
>
> void WINAPI foo()
> {
> APPLICATION_RECOVERY_CALLBACK bar;
> unsigned int (WINAPI *baz)(void*);
> }
OK, so it's being that attributes with effect only on function
bodies are harmless on function types / indirect calls. Of
course in case the user expects sth like a thunk to be generated
for calls through such type then a warning that the attribute has
no effect is warranted.
I'd vote for splitting -Wattributes to distinguish
t.c:2:1: warning: ‘ms_ho_prologue’ attribute directive ignored
[-Wattributes]
void __attribute__((__ms_ho_prologue__)) bar () {}
^~~~
t.c:4:1: warning: ‘ms_hook_prologue’ attribute only applies to functions
[-Wattributes]
typedef void __attribute__((__ms_hook_prologue__)) (*fn_t)();
so you could disable the second while retaining the first. You
could be also more careful in the source where you place the
attributes...
Richard.
