From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23766 invoked by alias); 11 Aug 2017 15:16:24 -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 126697 invoked by uid 89); 11 Aug 2017 15:15:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-qk0-f194.google.com Received: from mail-qk0-f194.google.com (HELO mail-qk0-f194.google.com) (209.85.220.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Aug 2017 15:15:24 +0000 Received: by mail-qk0-f194.google.com with SMTP id x77so3753066qka.4 for ; Fri, 11 Aug 2017 08:15:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TVZuvR6nhF8B1ReKBfhrVQgZ37yvff0VqY2eDzMhd/I=; b=U6YEnnFbhiL4LaiF3HmW4PF5V+dZdJWuioh8a7CMxoyH/Cm3LWMyzateFofZ7NFkNs 43p7gxIqqsgsoZZNr8yojFIU3m9GSdf+uahTOg6MvcgFQ8kYbNUaUNxtG/Vdg4mjBczs 0BL7qJrxfoDRRRCkp6Nkn4GLJ4MtBkPkeKa6604yjnf6IoAFirjCKcwhCeUplffy7YsL 4tZWqSVW7bwKv2bLA9XW8wrj1NhFJ1EmqvApXe+BcjXDTtOY1dKW+FDGyQdmIBWSgC4g DRPuINSsoLtXzRAXzeAv1VESnvDI5yeSMy17X57Z9+/yuTnLNSDrWXp36ff7sh7oD0wS bdWA== X-Gm-Message-State: AHYfb5jdEcgVS5uiB4uGpCcCv93MGPWmh8hLisQo1560hBOiLVU8Mp9h VQNQdf9mshfbmw== X-Received: by 10.55.166.207 with SMTP id p198mr18773795qke.132.1502464516397; Fri, 11 Aug 2017 08:15:16 -0700 (PDT) Received: from localhost.localdomain (174-16-105-12.hlrn.qwest.net. [174.16.105.12]) by smtp.gmail.com with ESMTPSA id b68sm643158qkc.88.2017.08.11.08.15.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 08:15:15 -0700 (PDT) From: Martin Sebor Subject: Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544) To: Joseph Myers References: <20170809115341.GM17069@redhat.com> <52dbf0e4-09b3-f313-d6b1-92f0e5ac6c16@gmail.com> <0fc9f24b-f474-3ab5-e660-b206486cc644@gmail.com> Cc: Marek Polacek , Gcc Patch List , Jason Merrill Message-ID: <61464927-ba0d-860d-d08f-5d36d473e3c2@gmail.com> Date: Fri, 11 Aug 2017 16:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00797.txt.bz2 On 08/10/2017 03:55 PM, Joseph Myers wrote: > On Wed, 9 Aug 2017, Martin Sebor wrote: > >> The problem isn't that the declarations aren't merged at the call >> site but rather that the middle-end gives const precedence over >> pure so when both attributes are provided the former wins. > > But that precedence is correct. Any function with the semantics of const > also has the semantics of pure. The problem is that the function doesn't > have the semantics of the attribute it's declared with. And any > diagnostic based purely on the presence of both attributes would be > essentially a style diagnostic - for the style principle "if you have > multiple declarations of a function, they should have the same > information" - rather than "these attributes are inconsistent". I didn't mean to imply that the precedence is incorrect. But whichever alternative it chosen is going to be "wrong" for code written with an expectation of the opposite. (Though the consequences of choosing the more restrictive one when the definition doesn't support it are obviously worse.) So because specifying the two attributes on two distinct declarations raises the question of which one was meant it's worth pointing it out to the user. This is in line with how some more benign attribute conflicts are already diagnosed this way (e.g., hot and cold or always_inline and noinline). But I don't want us to get too bogged down in a discussion of these two or any other particular attributes at this point. I'd like to get the infrastructure into a shape where these choices can easily be made without changing the code or the data structures, simply by adjusting bits in the attribute_spec tables. (There are plenty of other mutually exclusive attributes that should be reviewed and perhaps adjusted.) > (An optional warning for different information in different declarations > is reasonable enough. Actually in glibc it would be useful to have a > warning for a different but related case - two functions both declared, > later one defined as an alias of another, but the declarations don't have > the same attributes. I'm pretty sure there are cases where the internal > declaration of __foo is missing attributes present on the public > declaration of foo. But such a warning for aliases is only appropriate > for attributes that are properties of the function, not attributes that > are properties of particular names for it - __foo may well be a hidden > symbol where foo isn't.) That does sound useful. With the last pushed declaration now available to the attribute handlers it should be fairly easy to detect this problem in handle_alias_ifunc_attribute. I'd be happy to look into implementing it after I'm done with this patch. Can you please open a bug to request it? Martin remind