From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96718 invoked by alias); 14 Dec 2018 04:04:05 -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 96708 invoked by uid 89); 14 Dec 2018 04:04:04 -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=alloc_size, bools, 88397 X-HELO: mail-qt1-f195.google.com Received: from mail-qt1-f195.google.com (HELO mail-qt1-f195.google.com) (209.85.160.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Dec 2018 04:04:02 +0000 Received: by mail-qt1-f195.google.com with SMTP id k12so4832359qtf.7 for ; Thu, 13 Dec 2018 20:04:02 -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=VnCxMT4ND8+sDV8VEvZAun5gY17YxVhoE0KitMEDbrI=; b=NuIuh1WhKFgEoaZvVPSE0xm8UxrYVOBFjlrUPa7g8c2ZTArnNnJCctbC0tcevjeCoQ ZkSy20113CLWn3x8Q9tm4PAVXxXLXk/gXEWhwcsSVFaVFk3TVyBKq/uroy6/Y4xzAm2j bQzj3F/Dqcq5WE6SQgIeQfAZK01KAUvdACTuDtS50soaP8Flx0QpYQ5VW6NHHZppfdgr d/uFl6tiLjYLrqaFVNsVFQyorgRXtLhZOSZqj9aEdrOELHPakXwN2/59axy8vvazGssD BJuyqhNyfaKSceLYPT6Y1DdLq7JN4tS1wtopkIJB9dwtxwjpKJVeJR1piqNjxlV7IIUY x0Ww== Return-Path: Received: from localhost.localdomain (97-118-99-160.hlrn.qwest.net. [97.118.99.160]) by smtp.gmail.com with ESMTPSA id a3sm2979322qta.21.2018.12.13.20.03.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Dec 2018 20:03:59 -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> From: Martin Sebor Message-ID: <5c5214f3-3165-707b-4e43-bfac000851a6@gmail.com> Date: Fri, 14 Dec 2018 04:04: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: <20181213233954.GH12380@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg01013.txt.bz2 On 12/13/18 4:39 PM, Jakub Jelinek wrote: > On Thu, Dec 13, 2018 at 02:05:29PM -0700, Martin Sebor wrote: >>> So how is the builtin defined then? Is the argument always an expression >>> and you only return whether its type has the attribute, or do something >>> different if the expression is of certain kind? >> >> For a DECL the built-in looks at both the DECL_ATTRIBUTES and >> the DECL's type's TYPE_ATTRIBUTES. For expressions, it just >> looks at TYPE_ATTRIBUTES of the expression's type. I'm not >> sure that this is necessarily the cleanest design but it's >> meant to follow how attributes are applied to DECLs. Sometimes >> they get applied to the DECL itself and other times to its type. >> This has been causing confusion to both users and GCC devs such >> as myself so at some point I'd like to make this clearer somehow. >> Not sure exactly how yet. > > But some users of the attribute look for the attribute on TYPE_ATTRIBUTES, > other on DECL_ATTRIBUTES, and the attributes have bools which say to what > they apply. So, I think the API need to be very clear whether the attribute > is on a decl or on a type. > > If it is similar to say sizeof/__alignof__ etc., where it accepts either > a type (for which one can use __typeof/decltype etc.), in which case it > would check the type attributes, or an expression and in that case require > it to be a decl and use decl attributes, one API is fine, but supporting > arbitrary expressions and sometimes looking at type, other times at decl > or both is not a good design. It's as good as the design of GCC attributes allows. Based on 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)); It wouldn't if the built-in differentiated between decls and types. Even if/when we make these function attributes (and others like it) apply to types as I think we should so it's possible to apply them to function pointers as users expect, there still will be others that will apply only to the function decls. The distinction between when GCC chooses to apply an attribute to a function decl vs to its type is not intuitive and cannot very well be, and neither would be an API that queried just a decl attribute or just a type attribute. The most common use case is to query whether a function has been declared with an attribute -- it doesn't matter whether it's on its unique type or on its decl. (The others might perhaps be useful too, but a lot less often.) Martin