Re: GCC 3.5 and debug info generation

[Michael Chastain <mec dot gnu at mindspring dot com>]

Hi Devang,

In the report:

   http://gcc.gnu.org/ml/gcc-testresults/2004-08/msg00833.html

The interesting for gcc folks is the list of regression PR's.
I take all the raw result differences, chase them down, and
file individual PR's for them.

The regression PR's for gcc are:

  . Gcc Regression Summary

    gcc HEAD versus gcc 3.4.1
      gcc/13974 gcc/14049
      gdb/1656 gdb/1734 gdb/1735

These PR's cover all the bad differences when I run the gdb test
suite with two different versions of gcc and compare the results.

The two gcc PR's are:

  gcc/13974  [3.5 regression] bad line marker in debug info

  This still happens with gcc HEAD 2004-08-17.

  gcc/14049  [3.5 regression] bad debug block info, dwarf-2, c++

  This PR is a bit confusing because it describes two separate gcc bugs.
  I thought they were two manifestations of the same bug, but then
  one test program "block.c" started working and the other test program
  "scope.c" did not.

  I don't know if the bug with "scope.c" has been fixed or not.  The gdb
  test case that led to this PR got broken by the new warning for
  'implicit definition of builtin function', so I haven't checked on
  this bug lately.  After the gdb test case gets fixed, I'll look and
  see if this bug has been fixed in gcc.

  (Of course the PR has a small example program in it and the
  "instructions to reproduce" involve the small example program and
  not "set up the whole gdb test suite and run it".  But I've got
  too many windows open right now even to play with the small example
  program.)

The three gdb PR's are:

  gdb/1656   if gdb cannot find function return value location,
             random uninitialized value is used

  gcc emits different code than it used to, and gdb can't handle it.
  The code is proper; that is why this is a gdb PR, not a gcc PR.
  I haven't checked the status of this lately.

  gdb/1734   gdb loses the name of an empty class

  gcc changed its debug info from gcc 3.4.1 to gcc HEAD: gcc no longer
  emits debug info for un-generated synthetic methods.  This is an
  improvement in gcc, but it exposes a bug in gdb.

  gdb/1735   schedlock.c, thread-specific.c don't compile with gcc HEAD

  This is a bug in the gdb test suite.  gcc sprouted a new warning
  for this code:

    unsigned int args[NUM+1];
    int *myp = &args[my_number];

  This will get fixed soon.

Plus there are two more gdb PR's that I failed to list in the report:

  gdb/1742   gdb.mi/*.c does not compile with gcc HEAD 20040806
  gdb/1743   gdb.threads/*.c does not compile with gcc HEAD 20040806

  These are caused by the new warning for "implicit declaration of
  built-in function".  They will be fixed soon.

By numerical count, most of the regressions in gdb test results
come from gdb/1742 and gdb/1743.  Fixes for these are in progress.

By the way, I could not find a way to disable the warning for
"implicit declaration of built-in function" short of disabling
all warnings with "-w".  That was a problem for me, and I suspect
it will be a problem for other gcc users as well.

There are more sections in my report:

  gcc gcc-3_4-branch versus gcc 3.4.1
    no regressions
    gcc/13956 has been fixed

  gcc gcc-3_3-branch versus gcc 3.3.4
      no improvements and no regressions

    Branches have been pretty healthy.  After gcc 3.X.0 is released,
    I've rarely, if ever, seen a regression from the released gcc
    to the gcc-3_X-branch.  If I do, I make sure to file PR's and
    email the release manager.

  gcc 3.4.1 versus gcc 3.3.4
    gcc/12267 gcc/13708 gcc/13956
    gdb/1537 gdb/1540

    On the other hand, gcc 3.3.4 to gcc 3.4.1 has problems!

  3.3.4 versus gcc 2.95.3
    not analyzed

    I have the raw data for this, but I haven't analyzed it.

    The biggest problem when upgrading from gcc 2.95.3 to gcc 3.3.4
    is the C++ ctor/dtor problem.  gcc 2.95.3 emits a single object
    code function for each ctor and dtor, and gdb can put breakpoints
    in them.  gcc 3.X emits multiple object code functions and gdb
    doesn't handle this.