Re: [PATCH] detect attribute mismatches in alias declarations (PR 81824)

[Joseph Myers <joseph@codesourcery.com>]

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