From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6671 invoked by alias); 24 Sep 2014 17:59:06 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 6656 invoked by uid 89); 24 Sep 2014 17:59:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 24 Sep 2014 17:59:04 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8OHwvEr020519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 24 Sep 2014 13:58:57 -0400 Received: from [10.10.51.195] (vpn-51-195.rdu2.redhat.com [10.10.51.195]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8OHwutm030697; Wed, 24 Sep 2014 13:58:56 -0400 Message-ID: <5423065F.7020308@redhat.com> Date: Wed, 24 Sep 2014 17:59:00 -0000 From: Andrew MacLeod User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Segher Boessenkool CC: Jakub Jelinek , Bernd Schmidt , gcc-patches , richard.sandiford@arm.com Subject: Re: parallel check output changes? References: <541AD692.4030907@redhat.com> <20140918130109.GH17454@tucnak.redhat.com> <541AD880.7080703@redhat.com> <541AF451.3070406@redhat.com> <541B1710.8060809@codesourcery.com> <20140918173609.GM17454@tucnak.redhat.com> <20140918184455.GB28595@gate.crashing.org> <20140919093723.GA26414@gate.crashing.org> <87iokel5c0.fsf@e105548-lin.cambridge.arm.com> <5422DB41.1090800@redhat.com> <20140924161039.GA27079@gate.crashing.org> <5422F174.2020001@redhat.com> In-Reply-To: <5422F174.2020001@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg02166.txt.bz2 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