c++/7580: incorrect/unfortunate DWARF-2 info for static const int class members

[carlton at math dot stanford dot edu]

>Number:         7580
>Category:       c++
>Synopsis:       incorrect/unfortunate DWARF-2 info for static const int class members
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Aug 12 12:56:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     carlton@math.stanford.edu
>Release:        GCC 3.1
>Organization:
>Environment:
gcc -v says:
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ../gcc-3.1/configure --enable-languages=c++
Thread model: single
gcc version 3.1

uname -a says:
Linux jackfruit.Stanford.EDU 2.4.18-5 #1 Mon Jun 10 15:31:48 EDT 2002 i686 unknown
>Description:
When compiling C++ code containing classes that have static members (especially unitialized and unreferenced static const int members), GCC generates DWARF-2 debugging information that seems to me incorrect and/or unfortunate in a couple of ways:

* As far as I can tell, when generating debugging information for classes containing static data members, the declarations for those members are tagged as DW_TAG_variable rather than DW_TAG_member.  These seems to me to clearly go against what the DWARF-2 stardard says; I gave some reasons why I believe this (with quotes from the standard) in <http://sources.redhat.com/ml/gdb/2002-08/msg00082.html>.  This isn't a serious bug, since GDB agrees with GCC on this, but I think it's a bug nonetheless.

* Also, when compiling code containing a class with a static const integral member that is both uninitialized and unreferenced, GCC emits debugging information as if there were a declaration for that member outside of the definition of the class.  I don't have any reason to believe that this is illegal (though it might be), but comments in dwarf2out.c seem to suggest that GCC tries to avoid emitting debugging information in such circumstances, and it certainly makes GDB unhappy.  So, on the one hand, this may well be more of a GDB bug than a GCC bug; but, on the other hand, it's probably unfortunate that GCC is emitting this debugging information, given that GCC tries to avoid emitting such information in other similar circumstances.
>How-To-Repeat:
Compile the following program with GCC 3.1, with debugging turned on:

  class C {
    static const int foo;
  };

  int main()
  {
  }

Then look at the debugging information. You'll see debugging info for the struct (which refers to C::foo as a DW_TAG_variable rather than a DW_TAG_member, as I mentioned in my first point above), then debugging info for various types, then debugging info for main(), then debugging info for an empty struct that I assume the compiler generates, then debugging info for a declaration of C::foo (this is the declaration that I refer to in my second point above), then debugging info for a type.

To see how the unnecessary second declaration of C::foo affects GDB, run GDB on this program, then do
  (gdb) b main
  (gdb) run
  (gdb) p C::foo
and you'll see:
  Cannot access memory at address 0x0
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: