From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26534 invoked by alias); 15 Dec 2018 00:18:13 -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 26521 invoked by uid 89); 15 Dec 2018 00:18:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=benefits, Those, Hx-languages-length:2437 X-HELO: mail-qt1-f193.google.com Received: from mail-qt1-f193.google.com (HELO mail-qt1-f193.google.com) (209.85.160.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 15 Dec 2018 00:18:10 +0000 Received: by mail-qt1-f193.google.com with SMTP id e5so8159508qtr.12 for ; Fri, 14 Dec 2018 16:18:10 -0800 (PST) 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=qk1gIIPZpybfP85AsPI45zcFsC4uj2Xms8ywdLvF7ko=; b=mmF/GxH0EC01QvSI8FJDw8T5mHNjNkrTCnmFt/Tb6AZ6TAb/fE9oBSDC5EuW1D4cAG Qhdubo160eAbm9H/cmqx28wVvw9zeUWEu7wW1r2l4ZvtK9vbDyWG98KgHPMt7yvvRZ6f ugpFvn1BuupqZ40wWIfQAk6CHUHw8cepGdfeXOEw02q8yrLgtP9GW45BH5HQ4+IpgCkV FvGmYBKEAmDGFutBrRelV9mh5DNecp71adQkqWBEKpTod4WZEts9xX23I9Zb63hrvh9X zJh8qLP5S6RVc+pLOooLq+fQLh3t/hs9L0bbUpCmhtPSrtPOc1tD04MP0sV62TlxWIvJ jiCQ== Return-Path: Received: from localhost.localdomain (97-118-99-160.hlrn.qwest.net. [97.118.99.160]) by smtp.gmail.com with ESMTPSA id v22sm4057963qkl.27.2018.12.14.16.18.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Dec 2018 16:18:06 -0800 (PST) Subject: Re: [PATCH] handle expressions in __builtin_has_attribute (PR 88383) To: Jakub Jelinek Cc: Jeff Law , Gcc Patch List References: <6b1f15b6-1446-21a2-54aa-b92ec6b5541f@redhat.com> <5599edd4-61ad-24ce-d19e-376dd9398183@gmail.com> <688c62e2-966a-c950-ca63-b58003610c62@gmail.com> <20181213195651.GZ12380@tucnak> <4e9198aa-3348-c45f-e3e7-7b3c23f94190@gmail.com> <20181213233954.GH12380@tucnak> <5c5214f3-3165-707b-4e43-bfac000851a6@gmail.com> <20181214074124.GI12380@tucnak> From: Martin Sebor Message-ID: <158442e5-055c-c40a-925b-cee604888c0d@gmail.com> Date: Sat, 15 Dec 2018 00:18: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: <20181214074124.GI12380@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg01131.txt.bz2 >> the manual a function declaration like >> >> __attribute__ ((alloc_size (1), malloc)) >> void* allocate (unsigned); >> >> should have those two attributes applied to it. Yet, alloc_size >> is actually applied to its type (but not to its decl) while malloc >> to the function's decl but not its type (bug 88397). >> >> I'm pretty sure most users still expect the following to pass: >> >> _Static_assert (__builtin_has_attribute (allocate, alloc_size)); >> _Static_assert (__builtin_has_attribute (allocate, malloc)); > > Users shouldn't expect this. If anything, we should document what > attributes are type attributes and which attributes are declaration > attributes. I designed the built-in based on what I expect. The programs that care about whether a function is declared, say with attribute alloc_align or malloc, do not and should not have to worry about whether the attribute is on the decl or on its type -- in the expected use cases it makes no difference. Those that might care whether an attribute is on the type can easily check the type: __builtin_has_attribute (__typeof__ (allocate), alloc_size) (I would expect GCC to apply an attribute either to a decl or to a type but not to both.) I do agree that whether an attribute applies to a function or its type should be reviewed and where it makes sense documented. More than that, some attributes that currently only apply to function decls should be changed to apply to (function) types instead so that calls via pointers to such functions can get the same benefits as calls to the functions themselves. Malloc is an example (bug 88397). > With the way you're proposing, users could check the type attributes > simply through __typeof/decltype etc., but couldn't test solely the > declaration attributes. I'm not proposing anything -- what I described is the design. I don't know of a use case for testing the decl alone for attributes. In all those I can think of, what matters is the union of attributes between the decl and its type. But I'm not opposed to enhancing the function if an important use case does turn up that's not supported. For what you are asking for this should already do it so I don't see a need to change anything: #define decl_has_attribute(d, ...) \ (__builtin_has_attribute (d, __VA_ARGS__) \ && !__builtin_has_attribute (__typeof__ (d), __VA_ARGS__)) Martin