binutils-gdb/contrib/dg-extract-results.sh

500 lines
15 KiB
Bash
Raw Normal View History

#! /bin/sh
# For a specified tool and optional list of test variants, extract
# test results from one or more test summary (.sum) files and combine
# the results into a new test summary file, sent to the standard output.
# The resulting file can be used with test result comparison scripts for
# results from tests that were run in parallel. See usage() below.
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
# Copyright (C) 2008, 2009, 2010, 2012 Free Software Foundation
# Contributed by Janis Johnson <janis187@us.ibm.com>
#
# This file is part of GCC.
#
# GCC is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# GCC is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
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
# along with GCC; see the file COPYING. If not, write to
# the Free Software Foundation, 51 Franklin Street, Fifth Floor,
# Boston, MA 02110-1301, USA.
PROGNAME=dg-extract-results.sh
Merge dg-extract-results.{sh,py} from GCC upstream It has been a while since we don't sync this file with GCC upstream, and in the meantime some interesting things have happened. The most interesting is the inclusion of a new dg-extract-results.py which is apparently faster than its shell equivalent. This merge will probably fix the bug described in <https://sourceware.org/ml/gdb-patches/2014-12/msg00421.html> Though I am still proposing the patch for upstream GCC. Once it gets accepted, I will merge it too. OK to apply? gdb/testsuite/ChangeLog: 2014-12-15 Sergio Durigan Junior <sergiodj@redhat.com> Merge dg-extract-results.{sh,py} from GCC upstream (r210243, r210637, r210913, r211666, r215400, r215817). 2014-05-08 Richard Sandiford <rdsandiford@googlemail.com> * dg-extract-results.py: New file. * dg-extract-results.sh: Use it if the environment seems suitable. 2014-05-20 Richard Sandiford <rdsandiford@googlemail.com> * dg-extract-results.py (parse_run): Handle warnings that are printed before a test harness is run. 2014-05-25 Richard Sandiford <rdsandiford@googlemail.com> * dg-extract-results.py (Named): Remove __cmp__ method. (output_variation): Use a key to sort variation.harnesses. 2014-06-14 Richard Sandiford <rdsandiford@googlemail.com> * dg-extract-results.py: For Python 3, force sys.stdout to handle surrogate escape sequences. (safe_open): New function. (output_segment, main): Use it. 2014-09-19 Segher Boessenkool <segher@kernel.crashing.org> * dg-extract-results.py (Prog.result_re): Include options in test name. 2014-10-02 Segher Boessenkool <segher@kernel.crashing.org> * dg-extract-results.py (output_variation): Always sort if do_sum.
2014-12-16 01:34:24 +01:00
# Try to use the python version if possible, since it tends to be faster.
PYTHON_VER=`echo "$0" | sed 's/sh$/py/'`
if test "$PYTHON_VER" != "$0" &&
test -f "$PYTHON_VER" &&
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
python -c 'import sys, getopt, re, io, datetime, operator; sys.exit (0 if sys.version_info >= (2, 6) else 1)' \
Merge dg-extract-results.{sh,py} from GCC upstream It has been a while since we don't sync this file with GCC upstream, and in the meantime some interesting things have happened. The most interesting is the inclusion of a new dg-extract-results.py which is apparently faster than its shell equivalent. This merge will probably fix the bug described in <https://sourceware.org/ml/gdb-patches/2014-12/msg00421.html> Though I am still proposing the patch for upstream GCC. Once it gets accepted, I will merge it too. OK to apply? gdb/testsuite/ChangeLog: 2014-12-15 Sergio Durigan Junior <sergiodj@redhat.com> Merge dg-extract-results.{sh,py} from GCC upstream (r210243, r210637, r210913, r211666, r215400, r215817). 2014-05-08 Richard Sandiford <rdsandiford@googlemail.com> * dg-extract-results.py: New file. * dg-extract-results.sh: Use it if the environment seems suitable. 2014-05-20 Richard Sandiford <rdsandiford@googlemail.com> * dg-extract-results.py (parse_run): Handle warnings that are printed before a test harness is run. 2014-05-25 Richard Sandiford <rdsandiford@googlemail.com> * dg-extract-results.py (Named): Remove __cmp__ method. (output_variation): Use a key to sort variation.harnesses. 2014-06-14 Richard Sandiford <rdsandiford@googlemail.com> * dg-extract-results.py: For Python 3, force sys.stdout to handle surrogate escape sequences. (safe_open): New function. (output_segment, main): Use it. 2014-09-19 Segher Boessenkool <segher@kernel.crashing.org> * dg-extract-results.py (Prog.result_re): Include options in test name. 2014-10-02 Segher Boessenkool <segher@kernel.crashing.org> * dg-extract-results.py (output_variation): Always sort if do_sum.
2014-12-16 01:34:24 +01:00
> /dev/null 2> /dev/null; then
exec python $PYTHON_VER "$@"
fi
usage() {
cat <<EOF >&2
Usage: $PROGNAME [-t tool] [-l variant-list] [-L] sum-file ...
tool The tool (e.g. g++, libffi) for which to create a
new test summary file. If not specified then all
specified sum files must be for the same tool.
variant-list One or more test variant names. If the list is
not specified then one is constructed from all
variants in the files for <tool>.
sum-file A test summary file with the format of those
created by runtest from DejaGnu.
If -L is used, merge *.log files instead of *.sum. In this
mode the exact order of lines may not be preserved, just different
Running *.exp chunks should be in correct order.
EOF
}
# Write a message to the standard error.
msg() {
echo "$@" >&2
}
# Parse the command-line options.
VARIANTS=""
TOOL=""
MODE="sum"
while getopts "l:t:L" ARG; do
case $ARG in
l) VARIANTS="${VARIANTS} ${OPTARG}";;
t) test -z "$TOOL" || (msg "${PROGNAME}: only one tool can be specified"; exit 1);
TOOL="${OPTARG}";;
L) MODE="log";;
\?) usage; exit 0;;
esac
done
shift `expr ${OPTIND} - 1`
if test $# -lt 1 ; then
usage
exit 1
fi
TMPDIR=${TMPDIR-/tmp}
SUM_FILES="$@"
FIRST_SUM=$1
TMP=
trap 'EXIT_STATUS=$?; rm -rf $TMP && exit $EXIT_STATUS' 0
# Create a (secure) tmp directory for tmp files.
{
TMP=`(umask 077 && mktemp -d -q "${TMPDIR}/dg-combine-results-$$-XXXXXX") 2>/dev/null` &&
test -n "$TMP" && test -d "$TMP"
} ||
{
TMP=${TMPDIR}/dg-combine-results-$$-$RANDOM
(umask 077 && mkdir $TMP)
} ||
{
msg "${PROGNAME}: cannot create a temporary directory"
{ (exit 1); exit 1; }
}
# Find a good awk.
if test -z "$AWK" ; then
for AWK in gawk nawk awk
do
if type $AWK 2>&1 | grep 'not found' > /dev/null 2>&1 ; then
:
else
break
fi
done
fi
# Verify that the specified summary files exist.
ERROR=0
for FILE in $SUM_FILES
do
if ! test -f $FILE ; then
msg "${PROGNAME}: file $FILE does not exist."
ERROR=1
fi
done
test $ERROR -eq 0 || exit 1
# Test if grep supports the '--text' option
GREP=grep
if echo -e '\x00foo\x00' | $GREP --text foo > /dev/null 2>&1 ; then
GREP="grep --text"
else
# Our grep does not recognize the '--text' option. We have to
# treat our files in order to remove any non-printable character.
for file in $SUM_FILES ; do
mv $file ${file}.orig
cat -v ${file}.orig > $file
done
fi
if [ -z "$TOOL" ]; then
# If no tool was specified, all specified summary files must be for
# the same tool.
CNT=`$GREP '=== .* tests ===' $SUM_FILES | $AWK '{ print $3 }' | sort -u | wc -l`
if [ $CNT -eq 1 ]; then
TOOL=`$GREP '=== .* tests ===' $FIRST_SUM | $AWK '{ print $2 }'`
else
msg "${PROGNAME}: sum files are for multiple tools, specify a tool"
msg ""
usage
exit 1
fi
else
# Ignore the specified summary files that are not for this tool. This
# should keep the relevant files in the same order.
SUM_FILES=`$GREP -l "=== $TOOL" $SUM_FILES`
if test -z "$SUM_FILES" ; then
msg "${PROGNAME}: none of the specified files are results for $TOOL"
exit 1
fi
fi
if [ "$TOOL" = acats ]; then
# Acats *.sum or *.log files aren't dejagnu generated, and they have
# somewhat different format.
ACATS_AWK=${TMP}/acats.awk
cat <<EOF > $ACATS_AWK
BEGIN {
print_prologue=1; curfile=""; insummary=0
passcnt=0; failcnt=0; unsupcnt=0; failures=""
}
/^[ \t]*=== acats configuration ===/ {
insummary=0
if (print_prologue) print
next
}
/^[ \t]*=== acats tests ===/ {
if (print_prologue) print
print_prologue=0
next
}
/^Running chapter / {
if (curfile) close (curfile)
curfile="${TMP}/chapter-"\$3
print >> curfile
next
}
/^[ \t]*=== acats Summary ===/ {
if (curfile) close (curfile)
curfile=""
insummary=1
next
}
/^# of expected passes/ { if (insummary == 1) passcnt += \$5; next; }
/^# of unexpected failures/ { if (insummary == 1) failcnt += \$5; next; }
/^# of unsupported tests/ { if (insummary == 1) unsupcnt += \$5; next; }
/^\*\*\* FAILURES: / {
if (insummary == 1) {
if (failures) sub(/^\*\*\* FAILURES:/,"")
failures=failures""\$0
}
}
{
if (print_prologue) { print; next }
if (curfile) print >> curfile
}
END {
system ("cat ${TMP}/chapter-*")
print " === acats Summary ==="
print "# of expected passes " passcnt
print "# of unexpected failures " failcnt
if (unsupcnt) print "# of unsupported tests " unsupcnt
if (failures) print failures
}
EOF
rm -f ${TMP}/chapter-*
$AWK -f $ACATS_AWK $SUM_FILES
exit 0
fi
# If no variants were specified, find all variants in the remaining
# summary files. Otherwise, ignore specified variants that aren't in
# any of those summary files.
if test -z "$VARIANTS" ; then
VAR_AWK=${TMP}/variants.awk
cat <<EOF > $VAR_AWK
/^Schedule of variations:/ { in_vars=1; next }
/^$/ { in_vars=0 }
/^Running target/ { exit }
{ if (in_vars==1) print \$1; else next }
EOF
touch ${TMP}/varlist
for FILE in $SUM_FILES; do
$AWK -f $VAR_AWK $FILE >> ${TMP}/varlist
done
VARIANTS="`sort -u ${TMP}/varlist`"
else
VARS="$VARIANTS"
VARIANTS=""
for VAR in $VARS
do
$GREP "Running target $VAR" $SUM_FILES > /dev/null && VARIANTS="$VARIANTS $VAR"
done
fi
# Find out if we have more than one variant, or any at all.
VARIANT_COUNT=0
for VAR in $VARIANTS
do
VARIANT_COUNT=`expr $VARIANT_COUNT + 1`
done
if test $VARIANT_COUNT -eq 0 ; then
msg "${PROGNAME}: no file for $TOOL has results for the specified variants"
exit 1
fi
cat $SUM_FILES \
| $AWK '/^Running/ { if ($2 != "target" && $3 == "...") print "EXPFILE: "$2 } ' \
| sort -u > ${TMP}/expfiles
# Write the begining of the combined summary file.
head -n 2 $FIRST_SUM
echo
echo " === $TOOL tests ==="
echo
echo "Schedule of variations:"
for VAR in $VARIANTS
do
echo " $VAR"
done
echo
# For each test variant for the tool, copy test reports from each of the
# summary files. Set up two awk scripts from within the loop to
# initialize VAR and TOOL with the script, rather than assuming that the
# available version of awk can pass variables from the command line.
for VAR in $VARIANTS
do
GUTS_AWK=${TMP}/guts.awk
cat << EOF > $GUTS_AWK
BEGIN {
variant="$VAR"
firstvar=1
expfileno=1
cnt=0
print_using=0
need_close=0
has_timeout=0
timeout_cnt=0
}
/^EXPFILE: / {
expfiles[expfileno] = \$2
expfilesr[\$2] = expfileno
expfileno = expfileno + 1
}
/^Running target / {
curvar = \$3
if (variant == curvar && firstvar == 1) { print; print_using=1; firstvar = 0 }
next
}
/^Using / {
if (variant == curvar && print_using) { print; next }
}
/^Running .*\\.exp \\.\\.\\./ {
print_using=0
if (variant == curvar) {
if (need_close) close(curfile)
curfile="${TMP}/list"expfilesr[\$2]
expfileseen[\$2]=expfileseen[\$2] + 1
need_close=0
testname="00"
next
}
}
/^\t\t=== .* ===$/ { curvar = ""; next }
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 12:23:59 +02:00
/^(PASS|XPASS|FAIL|XFAIL|UNRESOLVED|WARNING|ERROR|UNSUPPORTED|UNTESTED|KFAIL|KPASS|PATH|DUPLICATE):/ {
testname=\$2
# Ugly hack for gfortran.dg/dg.exp
if ("$TOOL" == "gfortran" && testname ~ /^gfortran.dg\/g77\//)
testname="h"testname
if ("$MODE" == "sum") {
if (\$0 ~ /^WARNING: program timed out/) {
has_timeout=1
timeout_cnt=cnt+1
} else {
# Prepare timeout replacement message in case it's needed
timeout_msg=\$0
sub(\$1, "WARNING:", timeout_msg)
}
}
}
/^$/ { if ("$MODE" == "sum") next }
{ if (variant == curvar && curfile) {
if ("$MODE" == "sum") {
# Do not print anything if the current line is a timeout
if (has_timeout == 0) {
# If the previous line was a timeout,
# insert the full current message without keyword
if (timeout_cnt != 0) {
printf "%s %08d|%s program timed out.\n", testname, timeout_cnt-1, timeout_msg >> curfile
timeout_cnt = 0
cnt = cnt + 1
}
printf "%s %08d|", testname, cnt >> curfile
cnt = cnt + 1
filewritten[curfile]=1
need_close=1
print >> curfile
}
has_timeout=0
} else {
filewritten[curfile]=1
need_close=1
print >> curfile
}
} else {
has_timeout=0
timeout_cnt=0
next
}
}
END {
n=1
while (n < expfileno) {
if (expfileseen[expfiles[n]]) {
print "Running "expfiles[n]" ..."
if (filewritten["${TMP}/list"n]) {
if (expfileseen[expfiles[n]] == 1)
cmd="cat"
else
cmd="LC_ALL=C sort"
if ("$MODE" == "sum")
system (cmd" ${TMP}/list"n" | sed -n 's/^[^ ]* [^ |]*|//p'")
else
system ("cat ${TMP}/list"n)
}
}
n = n + 1
}
}
EOF
SUMS_AWK=${TMP}/sums.awk
rm -f $SUMS_AWK
cat << EOF > $SUMS_AWK
BEGIN {
variant="$VAR"
tool="$TOOL"
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
passcnt=0; failcnt=0; untstcnt=0; xpasscnt=0; xfailcnt=0; kpasscnt=0; kfailcnt=0; unsupcnt=0; unrescnt=0; dgerrorcnt=0;
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 12:23:59 +02:00
pathcnt=0; dupcnt=0
curvar=""; insummary=0
}
/^Running target / { curvar = \$3; next }
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
/^ERROR: \(DejaGnu\)/ { if (variant == curvar) dgerrorcnt += 1 }
/^# of / { if (variant == curvar) insummary = 1 }
/^# of expected passes/ { if (insummary == 1) passcnt += \$5; next; }
/^# of unexpected successes/ { if (insummary == 1) xpasscnt += \$5; next; }
/^# of unexpected failures/ { if (insummary == 1) failcnt += \$5; next; }
/^# of expected failures/ { if (insummary == 1) xfailcnt += \$5; next; }
/^# of unknown successes/ { if (insummary == 1) kpasscnt += \$5; next; }
/^# of known failures/ { if (insummary == 1) kfailcnt += \$5; next; }
/^# of untested testcases/ { if (insummary == 1) untstcnt += \$5; next; }
/^# of unresolved testcases/ { if (insummary == 1) unrescnt += \$5; next; }
/^# of unsupported tests/ { if (insummary == 1) unsupcnt += \$5; next; }
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 12:23:59 +02:00
/^# of paths in test names/ { if (insummary == 1) pathcnt += \$7; next; }
/^# of duplicate test names/ { if (insummary == 1) dupcnt += \$6; next; }
/^$/ { if (insummary == 1)
{ insummary = 0; curvar = "" }
next
}
{ next }
END {
printf ("\t\t=== %s Summary for %s ===\n\n", tool, variant)
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
if (dgerrorcnt != 0) printf ("# of DejaGnu errors\t\t%d\n", dgerrorcnt)
if (passcnt != 0) printf ("# of expected passes\t\t%d\n", passcnt)
if (failcnt != 0) printf ("# of unexpected failures\t%d\n", failcnt)
if (xpasscnt != 0) printf ("# of unexpected successes\t%d\n", xpasscnt)
if (xfailcnt != 0) printf ("# of expected failures\t\t%d\n", xfailcnt)
if (kpasscnt != 0) printf ("# of unknown successes\t\t%d\n", kpasscnt)
if (kfailcnt != 0) printf ("# of known failures\t\t%d\n", kfailcnt)
if (untstcnt != 0) printf ("# of untested testcases\t\t%d\n", untstcnt)
if (unrescnt != 0) printf ("# of unresolved testcases\t%d\n", unrescnt)
if (unsupcnt != 0) printf ("# of unsupported tests\t\t%d\n", unsupcnt)
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 12:23:59 +02:00
if (pathcnt != 0) printf ("# of paths in test names\t%d\n", pathcnt)
if (dupcnt != 0) printf ("# of duplicate test names\t%d\n", dupcnt)
}
EOF
PVAR=`echo $VAR | sed 's,/,.,g'`
TMPFILE=${TMP}/var-$PVAR
rm -f $TMPFILE
rm -f ${TMP}/list*
cat ${TMP}/expfiles $SUM_FILES | $AWK -f $GUTS_AWK
cat $SUM_FILES | $AWK -f $SUMS_AWK > $TMPFILE
# If there are multiple variants, output the counts for this one;
# otherwise there will just be the final counts at the end.
test $VARIANT_COUNT -eq 1 || cat $TMPFILE
done
# Set up an awk script to get the combined summary counts for the tool.
TOTAL_AWK=${TMP}/total.awk
cat << EOF > $TOTAL_AWK
BEGIN {
tool="$TOOL"
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
passcnt=0; failcnt=0; untstcnt=0; xpasscnt=0; xfailcnt=0; kfailcnt=0; unsupcnt=0; unrescnt=0; dgerrorcnt=0
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 12:23:59 +02:00
pathcnt=0; dupcnt=0
}
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
/^# of DejaGnu errors/ { dgerrorcnt += \$5 }
/^# of expected passes/ { passcnt += \$5 }
/^# of unexpected failures/ { failcnt += \$5 }
/^# of unexpected successes/ { xpasscnt += \$5 }
/^# of expected failures/ { xfailcnt += \$5 }
/^# of unknown successes/ { kpasscnt += \$5 }
/^# of known failures/ { kfailcnt += \$5 }
/^# of untested testcases/ { untstcnt += \$5 }
/^# of unresolved testcases/ { unrescnt += \$5 }
/^# of unsupported tests/ { unsupcnt += \$5 }
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 12:23:59 +02:00
/^# of paths in test names/ { pathcnt += \$7 }
/^# of duplicate test names/ { dupcnt += \$6 }
END {
printf ("\n\t\t=== %s Summary ===\n\n", tool)
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
if (dgerrorcnt != 0) printf ("# of DejaGnu errors\t\t%d\n", dgerrorcnt)
if (passcnt != 0) printf ("# of expected passes\t\t%d\n", passcnt)
if (failcnt != 0) printf ("# of unexpected failures\t%d\n", failcnt)
if (xpasscnt != 0) printf ("# of unexpected successes\t%d\n", xpasscnt)
if (xfailcnt != 0) printf ("# of expected failures\t\t%d\n", xfailcnt)
if (kpasscnt != 0) printf ("# of unknown successes\t\t%d\n", kpasscnt)
if (kfailcnt != 0) printf ("# of known failures\t\t%d\n", kfailcnt)
if (untstcnt != 0) printf ("# of untested testcases\t\t%d\n", untstcnt)
if (unrescnt != 0) printf ("# of unresolved testcases\t%d\n", unrescnt)
if (unsupcnt != 0) printf ("# of unsupported tests\t\t%d\n", unsupcnt)
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 12:23:59 +02:00
if (pathcnt != 0) printf ("# of paths in test names\t%d\n", pathcnt)
if (dupcnt != 0) printf ("# of duplicate test names\t%d\n", dupcnt)
}
EOF
# Find the total summaries for the tool and add to the end of the output.
cat ${TMP}/var-* | $AWK -f $TOTAL_AWK
# This is ugly, but if there's version output from the compiler under test
# at the end of the file, we want it. The other thing that might be there
# is the final summary counts.
tail -2 $FIRST_SUM | $GREP '^#' > /dev/null || tail -2 $FIRST_SUM
exit 0