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
