Commit Graph

8 Commits

Author SHA1 Message Date
Sam James
f9b7cc0cd2 contrib: sync dg-extract-results.sh with GCC
This syncs dg-extract-results.sh with GCC.

It contains two commits: r14-4333-g346f5991569fae and r14-9393-g64273a7e6bd8ba.

contrib/ChangeLog:
	* dg-extract-results.sh: Sync with GCC.

Approved-By: Tom Tromey <tom@tromey.com>
2024-03-12 15:49:25 +00:00
Sam James
a02a739070 contrib: sync dg-extract-results.py with GCC
This syncs dg-extract-results.py with GCC.

It contains only one commit: r14-7145-g8f67953d0198fe.

contrib/ChangeLog:
        * dg-extract-results.py: Sync with GCC.

Approved-By: Tom Tromey <tom@tromey.com>
2024-03-12 15:49:23 +00:00
Simon Marchi
ee1b8b9477 Import mklog.py from gcc repo
I've been using the mklog utility from the gcc repo for a while to
generate skeleton of ChangeLog entries.  It recently got a rewrite as a
Python script.  Unfortunately, to find the repository root, and
eventually to find in which ChangeLog file each entry goes, the new
script assumes it is located in the same git repository that it
generates ChangeLog entries for.

This means that if you make a change in the gcc source tree and run
mklog.py from that same source tree, it works.  But if you make changes
in your ~/src/binutils-gdb tree and run ~/src/gcc/contrib/mklog.py, it
won't work.

IIRC, the old script required that you ran it with the project's root
directory as the CWD.

The simplest way to fix this is to import the script in binutils-gdb and
use it from there.  It's also nice because we can use it without having
a clone of the gcc repo.

I also thought of adding a "--root" switch to the script to override the
project's base directory.  However:

1) It is more work.
2) If the script still lives in the gcc repo, it's less convenient than
   having it in binutils-gdb.

This patch imports contrib/mklog.py from the gcc repo, revision
c560591408440f441b8b327f5b41f9328d20b67b.

contrib/ChangeLog:

	* mklog.py: New file, imported from gcc.

Note: the ChangeLog entry above was generated using
`git show | ./mklog.py`!

Change-Id: I955592ce6397681986dc82a09593c32d8b8de54f
2020-09-25 10:24:44 -04:00
Andrew Burgess
c959562d9b contrib: Update dg-extract-results.* from gcc
Pull the latest version of the dg-extract-results.* scripts from the
gcc repository.  This picks up this commit from gcc:

  commit c9a41202b272b0b3a3c64a96ef4a5a97579eb017
  Date:   Mon May 11 22:32:35 2020 +0100

  contrib: Handle GDB specific test result types

  This commit is for the benefit of GDB, but as the binutils-gdb
  repository shares the contrib/ directory with gcc, this commit must
  first be applied to gcc then copied back to binutils-gdb.

  This commit extends the two scripts contrib/dg-extract-results.{py,sh}
  to handle some new, GDB specific test result types.  These test
  results types should never appear in GCC, or any other tool that
  shares the contrib/ directly, so this change should be harmless.

  In this patch series:
    https://sourceware.org/pipermail/gdb-patches/2020-April/167847.html
  changes were made in GDB's use of Dejagnu so that two additional
  conditions could be detected, these are:

    1. Test names that contain either the build or source paths.  Such
    test names make it difficult to compare the results of two test runs
    of GDB from two different directories, and

    2. Duplicate test names.  Duplicates make it difficult to track down
    exactly which test has failed.

  When running Dejagnu on GDB we can now (sometimes) see two additional
  test result types matching the above conditions, these are '# of paths
  in test names' and '# of duplicate test names'.

  If the test is run in parallel mode (make -j...) then these extra test
  results will appear in the individual test summary files, but are not
  merged into the final summary file.

  Additionally, within the summary file there are now two new types of
  test summary line, these are 'PATH: ...' and 'DUPLICATE: ...', these
  allow users to quickly search the test summary to track down where the
  offending test names are.  These lines are similarly not merged into
  the unified gdb.sum file after a parallel test run.

  This commit extends the dg-extract-results.* scripts to calculate the
  totals for the two new result types, and to copy the new test summary
  lines into the unified summary file.

contrib/ChangeLog:

	* dg-extract-results.py: Update from gcc repo.
	* dg-extract-results.sh: Likewise.
2020-05-15 11:41:22 +01:00
Andrew Burgess
66b92822fa contrib: Update dg-extract-results.* from gcc
The dg-extract-results scripts have been updated in the gcc
repository.  This commit copies the updated versions of the scripts in
to the binutils-gdb repository.

There are two changes, these are:

  1. Improved detection of timeout lines, though I suspect this only
  applies to gcc results, and

  2. Detection of KPASS results, this is of interest to gdb, where
  these results would not be included in the final .sum file.

A grep over binutils-gdb shows the dg-extract-results is not used by
ld, gas, or binutils, however I tested these anyway and saw no changes
in the final .sum files (tested on x86-64 GNU/Linux).

On gdb when running tests in parallel dg-extract-results is used, and
the final .sum file now includes the KPASS results.

contrib/ChangeLog:

	* dg-extract-results.py: Update from gcc repo.
	* dg-extract-results.sh: Likewise.

Change-Id: I54abd07f4e8f5cf88a6db74519674f6939860157
2019-10-21 15:26:48 +01:00
Rainer Orth
5a6996172e Update dg-extract-results.* from gcc
When looking at the gdb.sum file produced by dg-extract-results.sh on
Solaris 11/x86, I noticed some wrong sorting, like this:

PASS: gdb.ada/addr_arith.exp: print something'address + 0
PASS: gdb.ada/addr_arith.exp: print 0 + something'address
PASS: gdb.ada/addr_arith.exp: print something'address - 0
PASS: gdb.ada/addr_arith.exp: print 0 - something'address

Looking closer, I noticed that while dg-extract-results.sh had been
copied over from contrib in the gcc repo, the corresponding
dg-extract-results.py file had not.  The latter not only fixes the
sorting problem I'd observed, but is also way faster than the shell
version (like a factor of 50 faster).

Therefore I propose to update both files from the gcc repo.  The changes
to the .sh version are trivial, just counting the number of DejaGnu
ERROR lines, too.

The files are moved to toplevel contrib:

* This way, they can easily be used should someone decide to parallelize
  one or more of the binutils, gas, or ld testsuites.

* They are less easily overlooked for updates from the gcc repo when
  they reside in the same place in both.

* The test_summary script needs to live in contrib since the toplevel
  Makefile's mail-report.log target expects it there.

Tested on amd64-pc-solaris2.11 with

	make -j16 check
and
	make -j16 -k RACY_ITER=5 check


	gdb/testsuite:
	* dg-extract-results.sh: Move to toplevel contrib.
	* Makefile.in (check-parallel): Reflect dg-extract-results.sh move.
	* Makefile.in (check-parallel-racy): Likewise.

	contrib:
	* dg-extract-results.sh: Move from gdb/testsuite.
	Update from gcc repo.
	* dg-extract-results.py: New from gcc repo.
2018-08-06 16:05:16 +02:00
Ben Elliston
962c9e742f * contrib: Remove directory. 2006-04-10 00:41:43 +00:00
Nick Clifton
1dfa8174b2 New directory. Created to contain a copy of the texi2pod.pl script so that
it is in the same place as the version in the FSF GCC sources.
2002-07-03 11:20:13 +00:00