n4659 17.4 (Type equivalence) p1.3:
Two template-ids refer to the same class, function, or variable if
...
their corresponding non-type template arguments of integral or
enumeration type have identical values
...
It looks that for non-type template arguments the template type
equivalence is based on argument /value/ not /type/ (and value), so IMHO
gcc is correct where it considers foo<10u> and foo<10> to be the same
type, i.e. "refer to the same class"
FWIW, type_info reports the same class name for both templates, which
appears to be correct as per the above.
I would think someone from gcc might be more specific on why both
templates print 4294967286, and what debug info is actually stored by -g
in this case.
On 2/3/2018 6:18 PM, Roman Popov wrote:
I've just checked g++8.0.1 from trunk, and the problem is still there. And
same with Clang compiler.
This is indeed is a serious issue for me, since my Python scripts for gdb
expect reliable dynamic type identification. However gdb is
completely powerless here. So I'm forced to stay on older compiler.
Consider this case (Results with g++ 8.0.1)
#include <iostream>
struct base {
virtual void print() = 0;
};
template< auto IVAL>
struct foo : base {
decltype(IVAL) x = -IVAL;
void print() override { std::cout << x << std::endl; };
};
int main()
{
base * fu = new foo<10u>();
base * fi = new foo<10>();
fu->print();
fi->print();
return 0; // set breakpoint here
}:
Now check dynamic types in GDB:
(gdb) p *fu
warning: RTTI symbol not found for class 'foo<10u>'
$1 = warning: RTTI symbol not found for class 'foo<10u>'
warning: RTTI symbol not found for class 'foo<10u>'
{_vptr.base = 0x400bd0 <vtable for foo<10u>+16>}
(gdb) p *fi
(gdb) p *fi
$2 = (foo<10>) {<base> = {_vptr.base = 0x400bb8 <vtable for foo<10>+16>}, *x
= 4294967286*}
Here GDB picks wrong type!
In RTTI type names are different. And this is correct.
But in debuginfo both types have same name:
foo<10> {
unsigned x;
}
foo<10> {
int x;
}
So GDB picks the first one, which is wrong.
-Roman
2018-02-03 6:20 GMT-08:00 Paul Smith <psm...@gnu.org>:
On Fri, 2018-02-02 at 23:54 -0500, Simon Marchi wrote:
Your problem is probably linked to these issues, if you want to follow
them:
gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932
gdb: https://sourceware.org/bugzilla/show_bug.cgi?id=22013
As Carl said, it's a good idea to try with the latest version of both
tools, but I think the issue will still be present.
GCC changed how it outputs unsigned template parameters in the debug
info (from 2u to just 2), and it doesn't look like it's going to change
it back. So I suppose we'll have to find a way to make GDB deal with
it.
I also tried a couple of times [1][2][3] to get a discussion started on
the mailing lists for how to resolve this but didn't get any replies,
and I got busy with other things.
We really need to find someone who is knowlegeable on type lookup in
GDB. That person needs to engage with the experts on the GCC side and
hash out the right answer to this problem. In my experience, Jonathan
Wakely on the GCC side is extremely responsive, I'm just too much of a
tyro to be able to discuss it with him at the level needed to find a
solution.
I think it's an extremely serious issue, if GDB can't resolve some very
common (IME) types, but so far it hasn't risen to the level of getting
attention from those who have sufficient expertise to solve it.
[1] https://gcc.gnu.org/ml/gcc-help/2017-08/msg00120.html
[2] https://sourceware.org/ml/gdb/2017-08/msg00069.html
[3] https://sourceware.org/ml/gdb/2017-09/msg00042.html
