public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Andrew MacLeod <amacleod@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
	Bernd Schmidt <bernds@codesourcery.com>,
	       gcc-patches <gcc-patches@gcc.gnu.org>,
	richard.sandiford@arm.com
Subject: Re: parallel check output changes?
Date: Thu, 25 Sep 2014 17:02:00 -0000	[thread overview]
Message-ID: <20140925170232.GA3802@gate.crashing.org> (raw)
In-Reply-To: <54240905.70600@redhat.com>

On Thu, Sep 25, 2014 at 08:22:29AM -0400, Andrew MacLeod wrote:
> So to be fair, I could use test_summary, but I think the concern is 
> warranted because if this inconsistent ordering can happen to PASS, I 
> would expect the same non-deterministic behaviour if those tests happen 
> to FAIL.  we just have far less FAILS so we aren't seeing it with 
> test_summary at the moment...
> 
> Aggregating all my .sum files,  I see a sampling of about 257,000 PASSs, 
> whereas I see a total of 141 FAILs.  FAILs only account for < 0.06% of 
> the output. ( I'm getting an average of about 510 mis-ordered PASSs, so 
> it only affects a small portion of them as well.)

0.24% here (2241 FAILs, 917715 PASSes).

You're seeing about 1 in 500 misordered, so if it was independent (which
of course it is not) I should see it in the FAILs already.

> I would think the output of .sum needs to be consistent from one run to 
> the next in order for test_summary to consistently report its results as 
> well.

Yes.  There also is the problem of the summaries being messed up (which
they were already before the parallelisation changes, but now the result
is much worse).

I'll have another look.


Segher

  reply	other threads:[~2014-09-25 17:02 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
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 [this message]
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=20140925170232.GA3802@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=amacleod@redhat.com \
    --cc=bernds@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=richard.sandiford@arm.com \
    /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).