[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

msebor at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Jan 29 23:55:00 GMT 2018


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.


More information about the Gcc-bugs mailing list