From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68588 invoked by alias); 3 Jun 2019 08:25:59 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 68576 invoked by uid 89); 3 Jun 2019 08:25:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:CAMMLpe, bodies, winapi, *baz X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Jun 2019 08:25:58 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id EF229AF60; Mon, 3 Jun 2019 08:25:55 +0000 (UTC) Date: Mon, 03 Jun 2019 08:25:00 -0000 From: Richard Biener To: Alex Henrie cc: Joseph Myers , Martin Sebor , gcc-patches@gcc.gnu.org, msebor@gcc.gnu.org, Zebediah Figura Subject: Re: [PATCH] PR c/86407 - Add option to ignore fndecl attributes on function pointers In-Reply-To: Message-ID: References: <20190524035737.14107-1-alexhenrie24@gmail.com> <0c831fcb-9b7b-4aa3-8032-1d4b66da57b7@gmail.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1609908220-945607872-1559550355=:10704" X-SW-Source: 2019-06/txt/msg00038.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609908220-945607872-1559550355=:10704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Content-length: 3478 On Fri, 31 May 2019, Alex Henrie wrote: > On Fri, May 31, 2019 at 1:38 AM Richard Biener 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. ---1609908220-945607872-1559550355=:10704--