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 jos...@codesourcery.com
