sunday project, gdb, 2002-12-18

[Michael Elizabeth Chastain <mec at shout dot net>]

Highlights of this report:

. gcc did their grand merge.  The old gcc HEAD is now gcc-3_3-branch,
  and the basic improvements branch is now gcc HEAD.  This provoked a
  one new dwarf-2 regression.  That's the only regression I detected.

. Both gcc gcc-3_3-branch and gcc HEAD have serious regressions with
  stabs+ compared to gcc 3.2.1.  Affected test scripts are:
    gdb.c++/casts.exp
    gdb.c++/classes.exp
    gdb.c++/derivation.exp
    gdb.c++/inherit.exp
    gdb.c++/local.exp
    gdb.c++/pr-574.exp
    gdb.c++/virtfunc.exp
  These show up well in the "compare by gcc" tables.
  Look at:
    http://www.shout.net/~mec/sunday/2002-12-18/difference/gcc-17.html

. I downloaded my trees before ElenaZ's fix for gdb 669, so these reports
  do not reflect that fix yet.

. I dropped gcc 3.0.4, gcc 3.1, gcc 3.1.1, and gcc 3.2.  You no longer need
  a monitor the size of the main screen on the Starship Enterprise; the
  screen in your local sports bar is big enough.

My tables are here:

  http://www.shout.net/~mec/sunday/2002-12-18/index.html

Michael C

. Summary

  . Test Matrix

    . Matrix

      target      => native
      host        => i686-pc-linux-gnu%rh-8
      gdb         => 5.3, gdb_5_3-branch%20021218, HEAD%20021218
      gcc         => 2.95.3, 3.2-7-rh, 3.2.1, gcc-3_2-branch%20021218, gcc-3_3-branch%20021218, HEAD%20021218
      binutils    => 2.13.90.0.2-rh, 2.13.1, binutils-2_13-branch%20021218, HEAD%20021218
      libc        => 2.2.93-5-rh
      gformat     => dwarf-2, stabs+
      count          126 = 1 * 1 * 3 * (5*4+1) * 1 * 2

    . Notes

      target and host names are gnu triples with extra information after
      a '%' delimiter.

      versions which start with a number are official releases or snapshots.
      versions which start with a number and end with "-rh" are the
        vendor-supplied versions on my red hat linux host.
      versions named "HEAD" are the cvs HEAD.
      versions with any other name are cvs branches.
      cvs versions show the checkout date after a '%' delimiter.

    . libiberty

      Not tested yet (I need to update my test script).

    . gdb

      . Tables

        . http://www.shout.net/~mec/sunday/2002-12-18/index.html

      . Overview

        gdb 5.3:             0 build aborts, 0 test aborts, 377 attention lines
        gdb gdb_5_3-branch:  0 build aborts, 0 test aborts, 367 attention lines
        gdb HEAD:            0 build aborts, 0 test aborts, 396 attention lines

        An attention line is a test with an attention result in one or
        more configurations.

        An attention result is any result except PASS.  This includes
        ERROR, WARNING, FAIL, NOTE, KPASS, KFAIL, XPASS, XFAIL, UNRESOLVED,
        UNTESTED, UNSUPPORTED, and unknown results.

      . Old bugs fixed

        None detected.

      . New bugs detected

        pr gdb/900: gdb mishandles locals in C++ main with implicit return
        http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=900
        Probably a gcc bug.  I need a symtab maintainer to look into this.

. Test protocol changes since last report

  I dropped gdb 5.2.1 and gdb 5.2.91.

  I dropped gcc 3.0.4, gcc 3.1, gcc 3.1.1, and gcc 3.2.  There are no
  significant regressions from any of these compilers to gcc 3.2.1.
  Note that there are still regressions from gcc 2.95.3 to gcc 3.2.1.

  I added gcc gcc-3_3-branch, which was cut about a week ago.
  gcc-3_2-branch continues to show activity in the ChangeLogs and
  so I continue to test with that too.

  I rewrote the index.html page.  Let me know if it makes any difference.

  I added a "libc" attribute to the reports.  All of my test runs are
  with the vendor libc, but I'm a bit closer to testing with different
  libc's.

  I upgraded my baseline from tcl 8.3.4 to tcl 8.4.1.  There were no
  changes in results.

  I upgraded my baseline from expect 5.33.0 to expect 5.38.0.  There were
  no changes in results.

  I upgraded my baseline from dejagnu 1.4.2 + FernandoN KFAIL patch to
  dejagnu 1.4.3.  There were no changes in results.  I also ran a test
  series with sourceware cvs dejagnu, which came out the same.  Both
  dejagnu 1.4.3 and sourceware dejagnu support KFAIL.

  (In the winter, CPU cycles are nearly free, because they all end up
  as heat and I have to heat my apartment anyways).

. Baseline software

  . host i686-pc-linux-gnu%rh-8

    make 3.79.1
    binutils 2.13.1
    gcc 3.2.1
    flex 2.5.4
    bison 1.35
    tcl 8.4.1
    expect 5.38.0
    dejagnu 1.4.3

    The baseline software is used to build and test all the other software.
    It is not part of the test matrix.

. Analysis

  . libiberty

    . results

      . target native

        . host i686-pc-linux-gnu%rh-8

          No results available yet.

  . gdb

    The previous report was 2002-12-12:

      http://www.shout.net/~mec/sunday/2002-12-12/Analysis.txt

    . 5.3

      . gdb.c++/annota2.exp: annotate quit

          pr gdb/544: gdb.c++/annota2.exp: annotate-quit test sometimes fails
          http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=544
          Fluctuation in test result from unknown cause.

      . gdb.c++/anon-union.exp: print w 2
        gdb.c++/anon-union.exp: print w 3
        gdb.c++/anon-union.exp: print z 2
        gdb.c++/anon-union.exp: print z 3
          PASS -> FAIL

          pr gdb/900: gdb mishandles locals in C++ main with implicit return
          http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=900

          This is a new failure.  It appears to be a new bug in gcc HEAD.
          I have filed a gdb bug report so that we can track the problem.
          I would like the symtab maintainers to look at the bug report:
          if they agree that it is a gcc bug, I will file a gcc bug report.

          This appears to be a very specialized bug; I think it happens
          only when the user next's to the end of a C++ main function
          with an implicit return value.

      . gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily

	  pr gdb/568: GDB confused by messily-exiting multi-threaded programs
	  http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb&cmd=view&pr=568

	  Jim Blandy thinks that this test may depend on a race condition:

	    http://sources.redhat.com/ml/gdb-testers/2002-q4/msg00010.html

      . gdb.threads/schedlock.exp: *

          This test script is useless in this release because of a
          signed-versus-unsigned bug.

	  Daniel Jacobowitz has an obvious fix, which has been applied
	  to gdb HEAD:

	    http://sources.redhat.com/ml/gdb-patches/2002-10/msg00454.html

    . gdb_5_3-branch

      This branch has had little activity since the gdb 5.3 release.
      I looked in all the ChangeLogs and there is one administrative
      entry to bump the version to 5.3.0.90.

      . gdb.c++/annota2.exp: annotate quit
        gdb.c++/anon-union.exp: print w 2
        gdb.c++/anon-union.exp: print w 3
        gdb.c++/anon-union.exp: print z 2
        gdb.c++/anon-union.exp: print z 3
        gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily
        gdb.threads/schedlock.exp: *

          Same analysis as gdb 5.3.
          [Props to JimB!]

    . HEAD

      . gdb.c++/annota2.exp: annotate quit
      . gdb.threads/killed.exp: GDB exits after multi-threaded program exits messily

          Same analysis as gdb 5.3.

      . gdb.c++/try_catch.exp: continue to breakpoint: *

          New marker logic PASSed in all configurations.

      . gdb.mi/mi-basics.exp: environment-*

          New tests PASSed in all configurations.

      . gdb.mi/gdb669.exp: console and MI have same number of threads
        gdb.mi/gdb669.exp: -thread_list_ids
        gdb.mi/gdb669.exp: MI and console have same threads
        gdb.mi/gdb669.exp: finding threads in MI output

          Some configurations improved, and some configurations
          disimproved.  Looks like multi-threading still has issues.

          ElenaZ committed a fix for this so the next spin will pick
          up her fix.

      . gdb.threads/schedlock.exp: *

          Both good and bad changes.  This test is still in a state
          where it's better to analyze the absolute results than to
          compare results from date to date.