Compile this sample with clang++ (I used 12.0.1):

~~~
template<typename DataT, int n, const int c>
class Foo
{
public:
  DataT me[n];
  const int me2=c;
};

template<typename , int, const int c> class Foo;

int main()
{
  Foo<int, 2, 3> f;
  f.me[0] = 0;
  return 0; // break here
}
~~~

Corresponding DWARF: 
~~~
 36 0x00000052:   DW_TAG_class_type
 37                 DW_AT_calling_convention        (DW_CC_pass_by_value)
 38                 DW_AT_name      ("Foo<int, 2, 3>")
 39                 DW_AT_byte_size (0x0c)
 40                 DW_AT_decl_file ("~/bin/programs/template/tt.cc")
 41                 DW_AT_decl_line (2)
 42 
 43 0x0000005b:     DW_TAG_member
 44                   DW_AT_name    ("me")
 45                   DW_AT_type    (0x00000097 "int[2]")
 46                   DW_AT_decl_file       ("~/bin/programs/template/tt.cc")
 47                   DW_AT_decl_line       (5)
 48                   DW_AT_data_member_location    (0x00)
 49                   DW_AT_accessibility   (DW_ACCESS_public)
 50 
 51 0x00000068:     DW_TAG_member
 52                   DW_AT_name    ("me2")
 53                   DW_AT_type    (0x000000b2 "const int")
 54                   DW_AT_decl_file       ("~/bin/programs/template/tt.cc")
 55                   DW_AT_decl_line       (6)
 56                   DW_AT_data_member_location    (0x08)
 57                   DW_AT_accessibility   (DW_ACCESS_public)
 58 
 59 0x00000075:     DW_TAG_template_type_parameter
 60                   DW_AT_type    (0x000000a4 "int")
 61 
 62 0x0000007a:     DW_TAG_template_value_parameter
 63                   DW_AT_type    (0x000000a4 "int")
 64                   DW_AT_const_value     (2)
 65 
 66 0x00000080:     DW_TAG_template_value_parameter
 67                   DW_AT_type    (0x000000a4 "int")
 68                   DW_AT_name    ("c")
 69                   DW_AT_const_value     (3)
~~~

Due to the second declaration, there is no DW_AT_name for the first two parameters. This is legal C++ (and was seen in a real project with forward declerations) and legal dwarf (DW_AT_name is optional here according to the spec).

As there is no DW_AT_name, GDB won't create a symbol for the first two parameters and therefore thinks there is only one parameter (the third). See gdb/dwarf2/read.c:handle_struct_member_die().

This leads to the following bad behaviour:

~~~
(gdb) r
Starting program: ~/bin/programs/template/tt.clang 

Breakpoint 1, main () at tt.cc:15
15	  return 0; // break here
(gdb) pi
>>> p = gdb.lookup_symbol('f')
>>> t = p[0].type
>>> t.template_argument(0)
<gdb.Value object at 0x7f53180794b0>
>>> t.template_argument(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: No argument 1 in template.
>>> t.template_argument(2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: No argument 2 in template.
~~~

And yes, having the compiler always emit a DW_AT_name might be the better longterm solution. But as it is legal dwarf, GDB probably should be made more resiliant as well.

I already looked at it a bit, and think having GDB create a symbol with a name like "<unavailable_1>" (too have unique names) would be one possibile solution. However I struggled a bit with adding an attribute after the DIE is already parsed.
I might be able to get back to this at one point, but I thought I would open a bug anyway, in case someone more experienced with dwarf2/read.c wants to take a look.

Note, that https://sourceware.org/bugzilla/show_bug.cgi?id=15626 seems to have the same root cause, at least at first glance.