From: Andrew MacLeod <amacleod@redhat.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
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: Wed, 24 Sep 2014 17:59:00 -0000 [thread overview]
Message-ID: <5423065F.7020308@redhat.com> (raw)
In-Reply-To: <5422F174.2020001@redhat.com>
On 09/24/2014 12:29 PM, Andrew MacLeod wrote:
> On 09/24/2014 12:10 PM, Segher Boessenkool wrote:
>> On Wed, Sep 24, 2014 at 10:54:57AM -0400, Andrew MacLeod wrote:
>>> On 09/23/2014 11:33 AM, Richard Sandiford wrote:
>>>> 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.
>> With the parallellisation changes the output was pretty random
>> order. My
>> patch made that a fixed order again, albeit a different one from before.
>>
>>> Is this suppose to be resolved now? I'm still seeing some issues
>>> with a
>>> branch cut from mainline from yesterday. This is from the following
>>> sequence:
>>>
>>> check out revision 215511 , build, make -j16 check, make -j16 check,
>>> then compare all the .sum files:
>> I don't understand what exactly you did; you have left out some steps
>> I think?
>>
> What? no.. like what? check out a tree, basic configure and build
> from scratch (./configure --verbose, make -j16 all) and then run make
> check twice in a row.. literally "make -j16 -i check". nothing in
> between. so the compiler and toolchain are exactly the same. and
> different results. same way Ive done it forever. except I am still
> getting some different results from run to run. target is a normal
> build-x86_64-unknown-linux-gnu
>
> what I'm saying is something still isn't all getting sorted all the
> time (maybe if a section wasn't split up, it doesn't sort?), or all
> the patches to fix it aren't in, or there is something else still
> amok. Notice it isn't options that is the problem this time.. its the
> trailing line number of the test case warning. One is in numerical
> order, the other is in alphabetical order.
>
> Im running it a third time now.. we'll see if its different than both
> the others or not.
>
> Andrew
AH. interesting.
The third run has a gcc.sum that is exactly the same as the first run.
so only the second run differs, and it seems to be from an alphabetical
sort. So run 3 and 1 match.
the gfortran.sum from the third run is identical to the *second* run,
but it is different from the *first* run. so run 2 and 3 match.
the two runs that match (2nd and 3rd run) look like:
PASS: gfortran.dg/coarray/this_image_1.f90 -fcoarray=single -O2 (test
for excess errors)
PASS: gfortran.dg/coarray/this_image_1.f90 -fcoarray=single -O2
execution test
PASS: gfortran.dg/coarray/this_image_1.f90 -fcoarray=lib -O2
-lcaf_single (test for excess errors)
PASS: gfortran.dg/coarray/this_image_1.f90 -fcoarray=lib -O2
-lcaf_single execution test
PASS: gfortran.dg/coarray/this_image_2.f90 -fcoarray=single -O2 (test
for excess errors)
PASS: gfortran.dg/coarray/this_image_2.f90 -fcoarray=single -O2
execution test
PASS: gfortran.dg/coarray/this_image_2.f90 -fcoarray=lib -O2
-lcaf_single (test for excess errors)
PASS: gfortran.dg/coarray/this_image_2.f90 -fcoarray=lib -O2
-lcaf_single execution test
and the odd one out (firstrun:)
PASS: gfortran.dg/coarray/this_image_1.f90 -fcoarray=lib -O2
-lcaf_single (test for excess errors)
PASS: gfortran.dg/coarray/this_image_1.f90 -fcoarray=lib -O2
-lcaf_single execution test
PASS: gfortran.dg/coarray/this_image_1.f90 -fcoarray=single -O2 (test
for excess errors)
PASS: gfortran.dg/coarray/this_image_1.f90 -fcoarray=single -O2
execution test
PASS: gfortran.dg/coarray/this_image_2.f90 -fcoarray=lib -O2
-lcaf_single (test for excess errors)
PASS: gfortran.dg/coarray/this_image_2.f90 -fcoarray=lib -O2
-lcaf_single execution test
PASS: gfortran.dg/coarray/this_image_2.f90 -fcoarray=single -O2 (test
for excess errors)
PASS: gfortran.dg/coarray/this_image_2.f90 -fcoarray=single -O2
execution test
looks like the first run was sorted, and the other 2 weren't.
There must be some condition under which we don't sort the results? or
another place which needs to be tweaked to do the sort as well...?
Andrew
next prev parent reply other threads:[~2014-09-24 17:59 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 [this message]
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=5423065F.7020308@redhat.com \
--to=amacleod@redhat.com \
--cc=bernds@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--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).