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
