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)
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