From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51423 invoked by alias); 1 Oct 2018 23:00:39 -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 51405 invoked by uid 89); 1 Oct 2018 23:00:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=relating, extent X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 01 Oct 2018 23:00:36 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1g77B4-0003YO-0G from joseph_myers@mentor.com ; Mon, 01 Oct 2018 16:00:34 -0700 Received: from digraph.polyomino.org.uk (137.202.0.90) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 2 Oct 2018 00:00:30 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.90_1) (envelope-from ) id 1g77Az-0006El-TG; Mon, 01 Oct 2018 23:00:29 +0000 Date: Mon, 01 Oct 2018 23:47:00 -0000 From: Joseph Myers To: Martin Sebor CC: Jason Merrill , Gcc Patch List Subject: Re: [PATCH] detect attribute mismatches in alias declarations (PR 81824) In-Reply-To: <42f8ec31-b967-08e7-ff7a-67a63a1a2a64@gmail.com> Message-ID: References: <42f8ec31-b967-08e7-ff7a-67a63a1a2a64@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2018-10/txt/msg00057.txt.bz2 On Mon, 1 Oct 2018, Martin Sebor wrote: > Testing the patch with Glibc triggers thousands of warnings of > both kinds. After reviewing a small subset it became apparent Thousands of warnings suggests initially having the warning outside -Wall (though one might hope to move it into -Wall at some point, depending on how hard the warnings are to address and to what extent they appear at all for other packages - most don't make heavy use of aliases like that - or failing that, to enable it explicitly for glibc once all the warnings are fixed, since this is certainly a useful warning for glibc showing issues we want to fix) - it's not like the typical case of a new warning where you can quickly and easily fix all the instances in glibc, for all architectures, to keep it building with mainline GCC. > attribute called copy. The attribute copies attributes from > one declaration (or type) to another. The attribute doesn't > resolve all the warnings but it helps. (For actual use in glibc that use would of course need to be conditional on a GCC version supporting the attribute.) > The class of warnings I noticed that can't be so easily handled > are due to inconsistencies between ifuncs and their resolvers. > One way to solve it might be to have resolvers automatically > "inherit" all the attributes of their targets (and enhance > GCC to warn for violations). Another way might be to expect > resolvers to be explicitly declared with attribute copy to copy > the attributes of all the targets (and also warn for violations). I'm not sure we should care about the attributes on IFUNC resolvers at all; no normal code will see a declaration of the resolver and also call the function, whereas lots of code calls functions under internal alias names that currently lack the same attributes as the public declaration has. It's also not obvious whether there might be more cases of attributes for a function that are inapplicable to IFUNC resolvers than just the attributes relating to a symbol rather than the function itself which are hardcoded as excluded. -- Joseph S. Myers joseph@codesourcery.com