public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Segher Boessenkool <segher@kernel.crashing.org>,
	       Bernd Schmidt <bernds@codesourcery.com>,
	       Andrew MacLeod <amacleod@redhat.com>,
	       gcc-patches <gcc-patches@gcc.gnu.org>,
	richard.sandiford@arm.com
Subject: Re: parallel check output changes?
Date: Tue, 23 Sep 2014 15:43:00 -0000	[thread overview]
Message-ID: <20140923154250.GQ17454@tucnak.redhat.com> (raw)
In-Reply-To: <87iokel5c0.fsf@e105548-lin.cambridge.arm.com>

On Tue, Sep 23, 2014 at 04:33:19PM +0100, Richard Sandiford wrote:
> FWIW, the \S+ thing was deliberate.  When one test is run multiple times
> with different options, those options aren't necessarily tried in
> alphabetical order.  The old sh/awk script therefore used just the test
> name as the key and kept tests with the same name in the order that
> they were encountered:
> 
> /^(PASS|XPASS|FAIL|XFAIL|UNRESOLVED|WARNING|ERROR|UNSUPPORTED|UNTESTED|KFAIL):/ {
>   testname=\$2
>   # Ugly hack for gfortran.dg/dg.exp
>   if ("$TOOL" == "gfortran" && testname ~ /^gfortran.dg\/g77\//)
>     testname="h"testname
> }
> 
> (note the "$2").  This means that the output of the script is in the same
> order as it would be for non-parallel runs.  I was following (or trying
> to follow) that behaviour in the python script.

My understanding was that the sh version sorts the testcase name followed
by the full line and then removes whatever has been there before the
PASS/XPASS etc., so while e.g. whether some test PASSed or FAILed etc.
is then more important than the option, if two tests PASS, the options are
still used for the sorting.  Note that before the parallelization changes,
usually the same test filename would be run all by a single runtest
instance, so it really didn't matter that much.

> Your patch instead sorts based on the full test name, including options,
> which means that the output no longer matches what you'd get from a
> non-parallel run.  AFAICT, it also no longer matches what you'd get from
> the .sh version.  That might be OK, just thought I'd mention it.

I'm afraid there is not enough info to reconstruct the order serial version
has.

	Jakub

  reply	other threads:[~2014-09-23 15:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-18 12:56 Andrew MacLeod
2014-09-18 13:08 ` Jakub Jelinek
2014-09-18 13:05   ` Andrew MacLeod
2014-09-18 15:45     ` Andrew MacLeod
2014-09-18 17:33       ` Bernd Schmidt
2014-09-18 17:36         ` Jakub Jelinek
2014-09-18 18:45           ` Segher Boessenkool
2014-09-19  9:37             ` Segher Boessenkool
2014-09-19 16:32               ` Mike Stump
2014-09-23 15:33               ` Richard Sandiford
2014-09-23 15:43                 ` Jakub Jelinek [this message]
2014-09-24 14:55                 ` Andrew MacLeod
2014-09-24 16:11                   ` Segher Boessenkool
2014-09-24 16:29                     ` Andrew MacLeod
2014-09-24 17:59                       ` Andrew MacLeod
2014-09-25 12:22                         ` Andrew MacLeod
2014-09-25 17:02                           ` Segher Boessenkool
2014-10-02 16:47                   ` Segher Boessenkool
2014-10-02 17:05                     ` Jakub Jelinek
2014-10-02 17:46                     ` Richard Sandiford
2014-10-02 18:00                       ` Jakub Jelinek
2014-10-04 10:32                         ` Richard Sandiford
2014-10-05 17:53                           ` Mike Stump
2014-10-02 18:15                       ` Segher Boessenkool
2014-10-02 19:05                         ` Andrew MacLeod

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140923154250.GQ17454@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=amacleod@redhat.com \
    --cc=bernds@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.sandiford@arm.com \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).