This is the mail archive of the gcc-testresults@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

sunday project, gdb, 2003-10-16


. Highlights of this report

  gcc gcc-3_3-branch 2003-10-16 03:32:20 UTC is healthy.

  This report does not cover gcc 3.3.2.  I plan to hit it in the
  next spin.

  The current tables are always at
    http://www.shout.net/~mec/sunday/current/index.html

Michael C

. Old Bugs Fixed

  None.

. New Bugs Detected

  http://sources.redhat.com/gdb/bugs/1405
  regression: print pEe->vd(), virtual baseclass botch, g++ 2.95.3 -gdwarf-2

    Broken again with vendor binutils and binutils HEAD.
    So now it is uniformly broken with all binutils.

. PR Count

  Query executed 2003-10-17 17:04:23 2003

  1421 matches found
    22 analyzed
   648 closed
    23 feedback
   715 open
     3 paperwork
    10 suspended
  1421 TOTAL

. Libiberty Testing

  . target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0, libc=2.2.93-5-rh
      binutils HEAD                                      714 tests, 31 failures
      gcc 2.95.3, binutils HEAD                          All 616 tests passed
      gcc 3.3.1, binutils HEAD                           649 tests, 0 failures
      gcc 3.3.2-20031007, binutils HEAD                  649 tests, 0 failures
      gcc gcc-3_3-branch, binutils 2.14                  649 tests, 0 failures
      gcc gcc-3_3-branch, binutils HEAD                  649 tests, 0 failures
      gcc gcc-3_3-branch, binutils vendor                649 tests, 0 failures
      gcc HEAD, binutils 2.14                            714 tests, 31 failures
      gcc HEAD, binutils HEAD                            714 tests, 31 failures
      gcc HEAD, binutils vendor                          714 tests, 31 failures
      gdb HEAD                                           714 tests, 31 failures
      gdb carlton_dictionary-branch                      714 tests, 31 failures
      gdb gdb_6_0-branch                                 649 tests, 0 failures

    These are long-standing demangler bugs.

      http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7986
      Problems with demangling (__cxa_demangle())

      http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11028
      The standalone C++ demangler doesn't work on some symbols

    A libiberty log is available at

      http://gcc.gnu.org/ml/gcc/2003-07/msg00032.html

. Gdb Testing

  My tables are at

    http://www.shout.net/~mec/sunday/2003-10-16/index.html

  The previous tables are at

    http://www.shout.net/~mec/sunday/2003-10-10/index.html

  . Non-PASS Results

    gdb 6.0             312 non-PASS results
    gdb gdb_6_0-branch  312 non-PASS results
    gdb HEAD            358 non-PASS results

  . 6.0

    . gdb.cp/annota2.exp: annotate-quit

        http://sources.redhat.com/gdb/bugs/544
        gdb.c++/annota2.exp: annotate-quit test sometimes fails

        Fluctuation in test result probably due to a signal handling
        race in the command loop.

    . gdb.mi/mi*-pthreads.exp: check mi_thread_command_set: -thread-select [3456]
        blank -> PASS
        PASS -> blank

        When gdb operates on an inferior program with threads, the
        thread library in the inferior program behaves differently: it
        generates more signals so that gdb can track events.

        This causes some programs to behave differently because they
        aren't prepared to handle the additional signals.  The test
        program for mi-pthreads.exp is such a program.

          http://sources.redhat.com/ml/gdb/2003-09/msg00279.html
          http://sources.redhat.com/gdb/bugs/259

    . gdb.threads/print-threads.exp: Hit thread_function breakpoint, 5 (slow with kill breakpoint)
        PASS -> blank
        blank -> PASS

        Fluctuation with unknown cause.  Probably harmless.

    . gdb.threads/schedlock.exp: *
        PASS
      gdb.threads/schedlock.exp: thread 0 ran (didn't run)
      gdb.threads/schedlock.exp: thread 1 ran (didn't run)
      gdb.threads/schedlock.exp: thread 2 ran (didn't run)
      gdb.threads/schedlock.exp: thread 3 ran (didn't run)
      gdb.threads/schedlock.exp: thread 4 ran (didn't run)
      gdb.threads/schedlock.exp: thread 5 ran (didn't run)
        PASS
        FAIL

        All tests PASSed in all configurations except for the
        "thread N ran" tests.  Here are the counts per thread.

                    PASS  FAIL
          thread 0     1    31
          thread 1    32     0
          thread 2    31     1
          thread 3    32     0
          thread 4    32     0
          thread 5    32     0

  . gdb gdb_6_0-branch

    checkout date is '2003-10-16 17:50:38 UTC'
    previous date is '2003-10-10 15:29:27 UTC'

    . gdb.cp/annota2.exp: annotate-quit

        Same analysis as gdb 6.0.

    . gdb.mi/mi*-pthreads.exp: check mi_thread_command_set: -thread-select [3456]
        PASS -> blank
        blank -> PASS

        Same analysis as gdb 6.0.

    . gdb.threads/print-threads.exp: Hit thread_function breakpoint, 5 (slow with kill breakpoint)
        PASS -> blank
        blank -> PASS

        Same analysis as gdb 6.0.

    . gdb.threads/schedlock.exp: *
        PASS
      gdb.threads/schedlock.exp: thread 0 ran (didn't run)
      gdb.threads/schedlock.exp: thread 1 ran (didn't run)
      gdb.threads/schedlock.exp: thread 2 ran (didn't run)
      gdb.threads/schedlock.exp: thread 3 ran (didn't run)
      gdb.threads/schedlock.exp: thread 4 ran (didn't run)
      gdb.threads/schedlock.exp: thread 5 ran (didn't run)
        PASS
        FAIL

        All tests PASSed in all configurations except for the
        "thread N ran" tests.  Here are the counts per thread.

                    PASS  FAIL
          thread 0     1    31
          thread 1    29     3
          thread 2    32     0
          thread 3    32     0
          thread 4    32     0
          thread 5    32     0

  . gdb HEAD

    checkout date is '2003-10-16 17:48:05 UTC'
    previous date is '2003-10-10 15:27:10 UTC'

    . gdb.base/call-rt-st.exp: finish out from loop_count (line 617)
        PASS -> blank
      gdb.base/call-rt-st.exp: finish out from loop_count (line 777)
      gdb.base/call-rt-st.exp: print print_bit_flags_char(*flags)
      gdb.base/call-rt-st.exp: print print_bit_flags_short(*flags)
        blank -> PASS

        Corinna V added two tests and changed the line number in an
        existing test.  All the new tests PASSed in all configurations.

    . gdb.cp/annota2.exp: annotate-quit

        Same analysis as gdb 6.0.

    . gdb.cp/virtfunc.exp: print pEe->vd()
        PASS -> FAIL

        There is a PR for this:

          http://sources.redhat.com/gdb/bugs/1405
          regression: print pEe->vd(), virtual baseclass botch, g++ 2.95.3 -gdwarf-2

        Broken again with vendor binutils and binutils HEAD.
        So now it is uniformly broken with all binutils.

    . gdb.mi/mi*-pthreads.exp: check mi_thread_command_set: -thread-select [3456]
        blank -> PASS
        PASS -> blank

        Same analysis as gdb 6.0.

    . gdb.threads/schedlock.exp: *
        PASS
      gdb.threads/schedlock.exp: thread 0 ran (didn't run)
      gdb.threads/schedlock.exp: thread 1 ran (didn't run)
      gdb.threads/schedlock.exp: thread 2 ran (didn't run)
      gdb.threads/schedlock.exp: thread 3 ran (didn't run)
      gdb.threads/schedlock.exp: thread 4 ran (didn't run)
      gdb.threads/schedlock.exp: thread 5 ran (didn't run)
        PASS
        FAIL

        All tests PASSed in all configurations except for the
        "thread N ran" tests.  Here are the counts per thread.

                    PASS  FAIL
          thread 0     2    30
          thread 1    30     2
          thread 2    32     0
          thread 3    32     0
          thread 4    32     0
          thread 5    32     0

. Test Matrix

  target     => native
  host       => i686-pc-linux-gnu
  osversion  => red-hat-8.0
  gdb        => 6.0, gdb_6_0-branch, HEAD
  gcc        => 2.95.3, 3.2-7-rh, 3.3.1, 3.3.2-20031007, gcc-3_3-branch, HEAD
  binutils   => 2.13.90.0.2-rh, 2.14, HEAD
  glibc      => 2.2.93-5-rh
  gformat    => dwarf-2, stabs+
  glevel     => 2
  count         96 = 1 * 1 * 1 * 3 * (5*3+1*1) * 1 * 2 * 1

  'target' and 'host' are gnu configuration triples.

  'osversion' is the host operating system name, which is additional
  information beyond 'host'.

  'gdb', 'gcc', 'binutils', and 'glibc' are version names.

  versions starting with a digit are official releases or snapshots.
  versions starting with a digit and ending with '-rh' are
    vendor-supplied official releases on my red hat linux host.
  versions named 'HEAD' are the cvs HEAD, also known as 'mainline' or 'trunk'.
  versions with any other name are cvs branches.

  'gformat' is the debugging information format.
  'glevel' is the debugging level.

  'count' is the total number of configurations tested.
  The vendor gcc is available only with vendor binutils,
    thus the '(5*3+1*1)' term for gcc/binutils combinations.

. Host Software

  . host=i686-pc-linux-gnu, osversion=red-hat-8.0

    make 3.79.1
    binutils 2.14
    gcc 3.3.1
    flex 2.5.4
    bison 1.875
    tcl 8.4.4
    expect 5.39
    dejagnu 1.4.3

  The sources.redhat.com cvs repository has its own versions of tcl,
  expect, and dejagnu.  I don't have the resources to test with both
  tcl/expect/dejagnu stacks, so I choose the stock stack for my test
  bed.
  
  The sources.redhat.com version of tcl is nearly identical to tcl
  8.4.1.  The sources.redhat.com version of expect dates from
  1998-06-15.  The sources.redhat.com version of dejagnu is nearly
  identical to dejagnu 1.4.3.

  I have packaged and published my scripts to manage the baseline
  software.  They are called Migchain (Michael's Gnu Toolchain) and
  Migbat (Michael's Gnu Build and Test), and they are licensed under the
  GPL.

    ftp://ftp.shout.net/pub/users/mec/migchain/migchain-0.6.tar.gz
    ftp://ftp.shout.net/pub/users/mec/migbat/migbat-0.6.tar.gz

. Test Bed Changes Since Last Report

  I upgraded host gcc from gcc 3.3 to gcc 3.3.1.  The host gcc is the
  gcc that I use to build binutils, gcc, and gdb for testing.  The host
  gcc is *not* used to build the gdb test suite programs, except for
  gdb.base/selftest.exp and gdb.gdb/*.exp, which operate on the gdb
  executable itself.  So the host version of gcc should not affect the
  test results; and of course, I did a little test spin to verify this.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]