From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57599 invoked by alias); 28 May 2019 19:05: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 57477 invoked by uid 89); 28 May 2019 19:05:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=targeted, wine, Presumably X-HELO: mail-oi1-f195.google.com Received: from mail-oi1-f195.google.com (HELO mail-oi1-f195.google.com) (209.85.167.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 May 2019 19:05:57 +0000 Received: by mail-oi1-f195.google.com with SMTP id f4so15158282oib.4; Tue, 28 May 2019 12:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gNQkwCN2jGfh/lOi9AZQswCvGQZSFwV7hI72hR1ezz4=; b=mB39mB0i7ua6lRkaxBaNE8xj1uVwstDd0QL9u/JC4fQUNY63C4OIkxktOcbV0uRolB HWSZ+V4zXkAJwh5xtWr1OU0SMkh4KQ66bob/TYgkB8yiZ+DW8SRPx/pTaiUMTqxlo9+I C+q3EpYsCIfzqMnyv7sVO+1CAiiXDa1UUDdy3Lo89vxKUBqBOKqeWX6NT6CCw3Iv9BWG pACxi0VWhN8NS0T6NnHttIPDmKnb3AcvS4Pve6do0rOmbuDuyweSYFSHiUAWFDIiRPXd mnj51JlR74qOC/mzzIo73gA2ELqyFqxCr+nSOy9IkblhUbi1eqJQtvHbdA1bAyH6Ptop oD+w== Return-Path: Received: from [192.168.0.41] (97-118-125-210.hlrn.qwest.net. [97.118.125.210]) by smtp.gmail.com with ESMTPSA id f4sm6392050oih.39.2019.05.28.12.05.53 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 28 May 2019 12:05:53 -0700 (PDT) Subject: Re: [PATCH] PR c/86407 - Add option to ignore fndecl attributes on function pointers To: Alex Henrie , Richard Biener Cc: gcc-patches@gcc.gnu.org, msebor@gcc.gnu.org References: <20190524035737.14107-1-alexhenrie24@gmail.com> From: Martin Sebor Message-ID: <0c831fcb-9b7b-4aa3-8032-1d4b66da57b7@gmail.com> Date: Tue, 28 May 2019 19:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg01851.txt.bz2 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. 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? 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