https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #14 from Martin Sebor <msebor at gcc dot gnu.org> --- Yes, the attribute affects all callers in the same translation unit and so it needs to match across both the declarations and the definition. I (and others) tested Glibc with this patch and if this had been an idiom there I would have seen it or heard about it. AFAIK, Glibc uses private symbols for internal calls and those are aliases for the external symbols. An alias can be declared with one attribute even though its target is declared with another, and GCC silently accepts it. This, however, is a potential bug that Joseph requested a warning for in pr81824. I promised I'd work on it after I was done with pr81544 but didn't get to it. You seem to be making the argument that this warning is valuable only if it points out bona fide bugs and that it is unacceptable when it, even in rare instances, is issued for strictly safe/correct code, no matter how contrived or esoteric the instances are and even if the code is questionable. That's not a realistic expectation to have. For every warning that points out a meaningless or ambiguous construct there will always be examples where the construct is safe. If we held all warnings to this standard then we'd have to cut the number of warnings GCC issues in half. Have you ever did an analysis of the rate of true vs false positives for -Wimplicit-fallthrough for instance? Or -Wignored-qualifiers, or -Wmissing-braces, or -Wparentheses, etc. For all of these one can come up with a more or less of an unusual use case that's not strictly incorrect but that GCC warns for regardless. In the cases of all these warning options we've accepted that the gains of the true positives outweigh the costs of false positives. And in some cases, the costs have been quite considerable. But the fact aside that this report is not an example of a false positive due to the use case you've contrived, I've seen no evidence that there are any cases like it in the wild at all. Even if there were some there aren't enough of them to be a concern since no bugs have been filed. If such examples come to light I'll certainly do my best to deal with them. But until then, I'd prefer to focus on fixing real bugs that have been reported for existing code to debating hypothetical problems.
