aboutsummaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
2020-05-15contrib: Update dg-extract-results.* from gccAndrew Burgess3-3/+20
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.
2019-10-21contrib: Update dg-extract-results.* from gccAndrew Burgess3-12/+60
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
2018-08-06Update dg-extract-results.* from gccRainer Orth3-0/+1056
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.
2006-04-10 * contrib: Remove directory.Ben Elliston2-438/+0
2002-07-03 New directory. Created to contain a copy of the texi2pod.pl script so thatNick Clifton2-0/+438
it is in the same place as the version in the FSF GCC sources.