Interestingly RTTI name also gives no guarantees: http://en.cppreference.com/w/cpp/types/type_info/name
<< Returns an implementation defined null-terminated character string containing the name of the type. No guarantees are given; in particular, the returned string can be identical for several types and change between invocations of the same program. >> It probably makes sense to look how g++ implements std::type_info::operator== . Probably there are some hints that GDB algorithm can utilize. Operator std::type_info::operator== must return true for equivalent types. 2018-02-05 8:59 GMT-08:00 Simon Marchi <simon.mar...@polymtl.ca>: > On 2018-02-05 11:45, Martin Sebor wrote: > >> Yes, with auto, the type of the constant does determine the type >> of the specialization of the template in the source code. >> >> In non-type template arguments, and more to the point I was making, >> in diagnostics, the suffix shouldn't or doesn't need to be what >> distinguishes the type of the template, even with auto. The part >> "with auto IVAL = 10" in the message >> >> 'void foo<IVAL>::print() [with auto IVAL = 10]': >> >> would be far clearer if auto were replaced by the deduced type, >> say along these lines: >> >> 'void foo<IVAL>::print() [with int IVAL = 10]': >> >> rather than relying on the suffix alone to distinguish between >> different specializations of the template. That seems far too >> subtle to me. But I think the diagnostic format is (or should >> be) independent of the debug info. >> > > That makes sense. > > With respect to the suffix, I keep coming back to the reality >> that even if GCC were to change to emit a format that GDB can >> interpret easily and efficiently, there still are other >> compilers that emit a different format. So the conclusion >> that a general solution that handles more than just one format >> (at least for non-type template arguments without auto) seems >> unescapable. >> > > If there are other compilers we wanted to support for which we can't trust > the template format, we could always ignore the template part of DW_AT_name > specifically for them. But since g++ and gdb are part of the same project > and are expected to work well and efficiently together, I would have hoped > that we could agree on a format so that gdb would not have to do the extra > work when parsing a g++-generated file (consequently the same format that > libiberty's demangler produces). > > Given the problem I illustrated in my previous mail, I don't have a > general solution to the problem to propose. > > Simon >
