From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61468 invoked by alias); 31 May 2019 07:38:34 -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 61341 invoked by uid 89); 31 May 2019 07:38:34 -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= 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; Fri, 31 May 2019 07:38:33 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id B1ED5ACC4; Fri, 31 May 2019 07:38:30 +0000 (UTC) Date: Fri, 31 May 2019 08:23: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: text/plain; charset=US-ASCII X-SW-Source: 2019-05/txt/msg02089.txt.bz2 On Thu, 30 May 2019, Alex Henrie wrote: > On Thu, May 30, 2019 at 6:59 PM Joseph Myers 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.