From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69746 invoked by alias); 29 Aug 2017 02:35:44 -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 69650 invoked by uid 89); 29 Aug 2017 02:35:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 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=Third, Attached X-HELO: mail-qt0-f196.google.com Received: from mail-qt0-f196.google.com (HELO mail-qt0-f196.google.com) (209.85.216.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Aug 2017 02:35:21 +0000 Received: by mail-qt0-f196.google.com with SMTP id e2so1920408qta.3 for ; Mon, 28 Aug 2017 19:35:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wcie4wMyK0uC2eQPMUr3SP+04Ga7RDc2Ih5a4NLWA5o=; b=VyEXx5htEBTPceJPbTQ1Q9jSE/ooHnFRfQthz1N2HGUD43koCdOm/zem66CRx6rTWe 6+pZ+JNmdPKEBRHMHR8DRcBdYIY4pineWR3YQG9lhW0IF1u/in9WBNOoX2EKQhBkvzlJ 55LhEI67hxE9fYbqP9UuoUk8UqHcRZM68A7dod7lDGWCdCKXd4H4TYQxZkp8IwpzHWU9 tCAIIl2pokO0k6Y2Q6or44i3eREnQsBUKRc0LEoWj2igG/sr7jf63CVgRXLL/ZGJtzNU Ow9SQ94HU8RCU0xuLKInGNa47q1HIfVvroVZRzgw/CATEEMe2KFclG4pTmX12b2uGKPE kSDQ== X-Gm-Message-State: AHYfb5jnLRcCHhHJEcTcTi6NcCcXcC6cM9AWEIR7XsnMvUpSWFiFCD28 iw5hH+B9gH7TG6Bz X-Received: by 10.237.62.82 with SMTP id m18mr3914697qtf.29.1503974119350; Mon, 28 Aug 2017 19:35:19 -0700 (PDT) Received: from localhost.localdomain (174-16-125-25.hlrn.qwest.net. [174.16.125.25]) by smtp.gmail.com with ESMTPSA id b62sm1277151qkg.89.2017.08.28.19.35.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Aug 2017 19:35:16 -0700 (PDT) Subject: Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544) To: Jeff Law , Richard Biener , Ian Lance Taylor References: <20170809115341.GM17069@redhat.com> <52dbf0e4-09b3-f313-d6b1-92f0e5ac6c16@gmail.com> <0fc9f24b-f474-3ab5-e660-b206486cc644@gmail.com> <61464927-ba0d-860d-d08f-5d36d473e3c2@gmail.com> <7e1f1d8c-a35f-ade5-76bd-b506c6d60e21@gmail.com> Cc: Joseph Myers , Marek Polacek , Gcc Patch List , Jason Merrill From: Martin Sebor Message-ID: Date: Tue, 29 Aug 2017 05:21: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: <7e1f1d8c-a35f-ade5-76bd-b506c6d60e21@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg01620.txt.bz2 Ping: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01087.html On 08/24/2017 02:43 PM, Martin Sebor wrote: > The bulk of this patch touches what I think is considered > the middle-end (attribs.c) so let me include its maintainers, > Ian, Jeff, and Richard: > > https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01087.html > > The high-level description and rationale for the change are > here: > > https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00602.html > > Thanks > Martin > > On 08/17/2017 10:03 AM, Martin Sebor wrote: >> Attached is an updated patch with just the minor editorial >> tweaks for the issues pointed out by Marek (stray comments >> and spaces), and with the C++ and libstdc++ bits removed >> and posted separately. I also added some text to the manual >> to clarify the const/pure effects. >> >> I thought quite a bit more about the const/pure attributes we >> discussed and tried the approach of warning only on a const >> declaration after one with attribute pure has been used, but >> otherwise allowing and silently ignoring pure after const. >> In the end I decided against it, for a few reasons (most of >> which I already mentioned but just to summarize). >> >> First, there is the risk that someone will write code based >> on the pure declaration even if there's no intervening call >> to the function between it and the const one. Code tends to >> be sloppy, and it's also not uncommon to declare the same >> function more than once, for whatever reason. (The ssa-ccp-2.c >> test is an example of the latter.) >> >> Second, there are cases of attribute conflicts that GCC already >> points out that are much more benign in their effects (the ones >> I know about are always_inline/noinline and cold/hot). In light >> of the risk above it seems only helpful to include const/pure in >> the same set. >> >> Third, I couldn't find another pair of attributes that GCC would >> deliberately handle this way (silently accept both but prefer one >> over the other), and introducing a special case just for these >> two seemed like a wart. >> >> Finally, compiling Binutils, GDB, Glkibc, and the Linux kernel >> with the enhanced warning didn't turn up any code that does this >> sort of thing, either intentionally or otherwise. >> >> With that, I've left the handling unchanged. >> >> I do still have the question whether diagnosing attribute >> conflicts under -Wattributes is right. The manual implies >> that -Wattributes is for attributes in the wrong places or >> on the wrong entities, and that -Wignored-attributes should >> be expected instead when GCC decides to drop one for some >> reason. >> >> It is a little unfortunate that many -Wattributes warnings >> print just "attribute ignored" (and have done so for years). >> I think they should all be enhanced to also print why the >> attribute is ignored (e.g., "'packed' attribute on function >> declarations ignored/not valid/not supported" or something >> like that). Those that ignore attributes that would >> otherwise be valid e.g., because they conflict with other >> specifiers of the same attribute but with a different >> operand might then be candidate for changing to >> -Wignored-attributes. >> >> Thanks >> Martin >> >