From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28750 invoked by alias); 29 May 2019 06:37:11 -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 28738 invoked by uid 89); 29 May 2019 06:37:10 -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; Wed, 29 May 2019 06:37:09 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 29648ACBC; Wed, 29 May 2019 06:37:07 +0000 (UTC) Date: Wed, 29 May 2019 07:16:00 -0000 From: Richard Biener To: Martin Sebor cc: Alex Henrie , gcc-patches@gcc.gnu.org, msebor@gcc.gnu.org Subject: Re: [PATCH] PR c/86407 - Add option to ignore fndecl attributes on function pointers In-Reply-To: <0c831fcb-9b7b-4aa3-8032-1d4b66da57b7@gmail.com> 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-1372216793-1559111827=:10704" X-SW-Source: 2019-05/txt/msg01869.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-1372216793-1559111827=:10704 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-length: 4509 On Tue, 28 May 2019, Martin Sebor wrote: > On 5/24/19 9:49 AM, Alex Henrie wrote: > > On Fri, May 24, 2019 at 2:01 AM Richard Biener wrote: > > > > > > I'm not sure we really need a new warning for this. > > > > On Fri, May 24, 2019 at 9:23 AM Martin Sebor wrote: > > > > > > I don't think GCC makes a formal distinction between function > > > attributes that affect only function definitions vs those that > > > affect its users, or both. It might be a useful distinction > > > to introduce, perhaps even for functions as well as variables, > > > but as it is, users (as well as GCC developers) are on our own > > > to figure it out. > > > > Then is it preferable to simply silence Wattributes in this case? > > This case being PR86407? I'd say yes. I think one general problem > to solve is the missing suppression for typedefs. This could be > useful for other warnings as well. Another is providing a knob to > control the warning when one kind of an attribute is used with > an entity of a different kind (function vs type, or variable vs > type). Yet another might be to control warnings for individual > attributes. > > > > > On Fri, May 24, 2019 at 2:01 AM Richard Biener wrote: > > > > > > > +int __attribute__((__ms_hook_prologue__)) func(); /* no warnings */ > > > > + > > > > > > But this is a declaration? > > > > On Fri, May 24, 2019 at 9:23 AM Martin Sebor wrote: > > > > > > My first question is: what is the meaning of "function definition > > > attributes?" Presumably those that affect only the definition of > > > a function and not its callers or other users? > > > > As far as I can tell, "fndecl" is a misnomer: these attributes are > > more accurately called "function definition attributes", i.e. > > attributes that affect the assembly code of the function but do not > > affect its calling convention. > > That's one possible definition but there are examples that don't > fit it (at least not very neatly). > > Attribute malloc attaches only to fndecl and not its type but > doesn't affect the code for a function definition. FWIW, I > think this is just a bug -- attribute malloc should apply > to a function type for the same reason the closely related > attribute alloc_size does. Yeah, we have existing attributes that do not apply well to indirect calls due to mistakes made in the past. Of course for things like 'malloc' this isn't a correctness issue. > Attribute constructor also attaches to a fndecl even though it > doesn't affect the function's codegen but that of its caller > (the runtime). In this case, though, I'd say that's fine. > Should it be classified as a function definition attribute? I think the issue is that internally we know what a fndecl is but that doesn't match what the C standard says is a function declaration. So it's important to not mix terms for GCC internals and terms used in diagnostics which generally should use terms from the language standard. > Attributes cold and hot also apply to a fndecl and not its type > but they affect both the function's definition and its callers. > I think this also makes sense. Should they be classified as > function definition attributes? > > > On Fri, May 24, 2019 at 9:23 AM Martin Sebor wrote: > > > > > > Finally, with this as a prerequisite, if we decided that a warning > > > like this would be useful, tests to verify that it works for all > > > the definition attributes and not for the rest would need to be > > > added (i.e., in addition to ms_hook_prologue). > > > > Okay, I will add tests for the other function attributes that should > > behave in the same way, commenting out the tests that will require > > more work to pass. > > > > The end goal is to include __ms_hook_prologue__ in the WINAPI macro on > > Wine without causing spurious warnings. This will go a long way > > towards making Wine compatible with current and future Windows > > programs. Thank you for help. > > Yes, I understand the goal. I'm not sure that the proposed change > is the right way to do it. It seems to me that a more targeted bug > to fix with the broadest benefit is that _Pragma GCC diagnostic (or > some such mechanism) cannot be used to suppress the warning for > typedefs. > > Martin > -- Richard Biener SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg) ---1609908220-1372216793-1559111827=:10704--