gcc HEAD, stabs+, TYPE_CODE_INT problem

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

My last test run got stabbed really badly by a new problem
with gcc HEAD -gstabs+.  There are about 700 new non-PASS results.

The symptoms are: look at a global variable of type "char *".

  # gcc 3.3.3
  (gdb) ptype s
  type = char *

  # gcc HEAD 2004-03-30
  (gdb) ptype s
  type = <invalid type code 7> *

"invalid type code 7" is TYPE_CODE_INT.

With gcc 3.3.3, the stabs look like this:

  # gcc 3.3.3
  .stabs	"char:t(0,2)=r(0,2);0;127;",128,0,0,0
  .stabs	"__caddr_t:t(7,35)=(7,36)=*(0,2)",128,0,82,0
  .stabs	"s:G(7,36)",32,0,7,0

With gcc HEAD, the stabs look like this:

  # gcc HEAD
  .stabs	"__caddr_t:t(3,44)=(3,45)=*(3,46)=r(3,46);0;127;",128,0,82,0
  .stabs	"s:G(3,45)",32,0,7,0

That is, gcc 3.3.3 emits a separate line for each primitive
type such as "char".  gcc HEAD emits the definition of "char"
as a nested definition inside the first type that uses char,
such as pointer-to-char.

The big question is: is this legal stabs?  After reading
stabs.texinfo, I'm inclined to think that it is.

If it's legal stabs, then someone has to enhance the stab reader.  I
haven't started debugging gdb yet but I suspect that bit of code is
getting confused by the new-style nested definition.  There's a bit of
code in read_range_type to recognize the special case of "char" as 0 to
127, and gdb is behaving like that special-case isn't getting
recognized.

If this code is *not* legal stabs, then I can make a small test case
and then file a gcc PR.  I already isolated the gcc patch which
causes this.  It's a big C-declaration rewrite.

Michael C