http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761
--- Comment #16 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Martin Jambor from comment #15) > (In reply to Manuel López-Ibáñez from comment #13) > > It is not clear to me why you want to print <clone> at all. It is an > > internal detail. > > ...just printing "<clone>" really provides fairly little value. If we > (hopefully from the next version on) manage to print details about > properties of the particular clone, it will become useful. I'm not entirely convinced by the arguments given above. Templated C++ code in diagnostics is already convoluted enough to add stuff that is not even in the language and that users will have no idea about. Imagine (real G++ output): std::basic_ostream<_CharT, _Traits>::__ostream_type& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT, _Traits>::__ostream_type& (*)(std::basic_ostream<_CharT, _Traits>::__ostream_type&)) [with _CharT = char, _Traits = std::char_traits<char>, std::basic_ostream<_CharT, _Traits>::__ostream_type = std::basic_ostream<char>] <clone> For developer/debug dumps, of course this doesn't apply, but this is not what this bug is about. (In reply to Marc Glisse from comment #14) > Imagine a function void f(unsigned a, unsigned b) where gcc makes a clone > specializing a=0. If the function contains a comparison a<=b, you might get > a warning because the comparison is always true. As a user, I would be quite > confused... This used to happen with template instantiations and it was considered a bug. That is, the compiler should not give that kind of warning for generated code if the original code does not show the same issue. If the original code shows the same issue, then we should give a warning for the original code. In general, there are at least two kinds of warnings: those for which there is a bug if we reach that code under certain conditions, and those for which the code looks suspicious but we cannot prove that there is a bug under any specific condition. Uninitialized warnings fall in the first category, whereas "comparison is always true/false" falls under the second one. The first kind of warnings would be improved by providing the exact conditions that may trigger the bug, whereas the second kind become noise if only triggered for specific conditions that are actually not present in the original code (like template specializations, macro expansion, and function cloning). For the first kind of bugs, if we explain the conditions better thanks to optimization, great, but saying: we warn because we created a clone of the function only leads to more questions: what is a clone? For the second kind, saying that we warn because we created a clone sounds more like an excuse than an actual analysis. ;-)
