From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130435 invoked by alias); 31 May 2019 20:34:08 -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 130396 invoked by uid 89); 31 May 2019 20:34:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=sk:__ms_ho X-HELO: mail-lf1-f65.google.com Received: from mail-lf1-f65.google.com (HELO mail-lf1-f65.google.com) (209.85.167.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 May 2019 20:34:06 +0000 Received: by mail-lf1-f65.google.com with SMTP id a25so8968782lfg.2; Fri, 31 May 2019 13:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XtdMfXCgCKKDYFV+JoPStvZPlVV5fyFyK3RnehNuzNk=; b=g6W7QD3Rx8SznXbMcERrcA8XjW1GqbpKqMOZe5nPKJdzTY7aUosPok77jOxnLSq5c9 6lJGGIHazCkvjor52AJHI0qO1Q0c2vK522gjqt3Nvpe6a/hLbb9QyY5yK5JSUPsbn8EQ NO7ZSOMLIr0D/VMhmahJ29oxyCNr4nOop1XwkSyww5ctiJDDpRaR0VoZrwz4oM40EMbo EbjIuJw0RHfeJenxrS4rroBEhO8Dg8I/JQQYyDkzXWkgsDoFUXtHsRQauXTBaDDd0QWM ptLkqWvNfLB+rt/6dbKFLl90SCYmq2wIUnBhA1DMF455zuaVBNhlKHUj75V/dfg0Auiq 5FZQ== MIME-Version: 1.0 References: <20190524035737.14107-1-alexhenrie24@gmail.com> <0c831fcb-9b7b-4aa3-8032-1d4b66da57b7@gmail.com> In-Reply-To: From: Alex Henrie Date: Fri, 31 May 2019 20:47:00 -0000 Message-ID: Subject: Re: [PATCH] PR c/86407 - Add option to ignore fndecl attributes on function pointers To: Richard Biener Cc: Joseph Myers , Martin Sebor , gcc-patches@gcc.gnu.org, msebor@gcc.gnu.org, Zebediah Figura Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg02170.txt.bz2 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*); } -Alex