This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544)
- From: Jeff Law <law at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Martin Sebor <msebor at gmail dot com>
- Cc: Marek Polacek <polacek at redhat dot com>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>
- Date: Tue, 12 Sep 2017 09:43:52 -0600
- Subject: Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E83094E33D
- References: <f48353a5-a1b9-6a2d-98c9-831c5d9d44a0@gmail.com> <20170809115341.GM17069@redhat.com> <52dbf0e4-09b3-f313-d6b1-92f0e5ac6c16@gmail.com> <alpine.DEB.2.20.1708091711010.18502@digraph.polyomino.org.uk> <c6150c61-3774-bfc7-b909-05efda68cfc4@gmail.com> <alpine.DEB.2.20.1708091949180.9262@digraph.polyomino.org.uk> <0fc9f24b-f474-3ab5-e660-b206486cc644@gmail.com> <alpine.DEB.2.20.1708102145580.8101@digraph.polyomino.org.uk>
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.
True. Pure/const is one of the cases where we have a clear subset
relationship. In the pure/const the worst that can happen is we don't
optimize as fully as we could (optimizing as pure then later see it as
const). I can't think of any correctness issues that can arise in the
pure/const scenario.
> The problem is that the function doesn't
> have the semantics of the attribute it's declared with.
I think this is the key realization for Martin's testcase. THe function
is declared const, but actually references global data. ISTM detecting
that would be a useful warning in and of itself.
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".
Right. This could be a warning unto itself when there's a
superset/subset relationship between the semantics of a particular pair
of attributes like we have with const/pure.
>
> (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.)
Yea, I can see how that would be useful.
jeff