parallel check output changes?

Richard Sandiford
Tue Sep 23 15:33:00 GMT 2014

Segher Boessenkool <> writes:
> On Thu, Sep 18, 2014 at 01:44:55PM -0500, Segher Boessenkool wrote:
>> I am testing a patch that is just
>> diff --git a/contrib/ b/contrib/
>> index cccbfd3..3781423 100644
>> --- a/contrib/
>> +++ b/contrib/
>> @@ -117,7 +117,7 @@ class Prog:
>>          self.tool_re = re.compile (r'^\t\t=== (.*) tests ===$')
>>          self.result_re = re.compile (r'^(PASS|XPASS|FAIL|XFAIL|UNRESOLVED'
>>                                       r'|WARNING|ERROR|UNSUPPORTED|UNTESTED'
>> -                                     r'|KFAIL):\s*(\S+)')
>> +                                     r'|KFAIL):\s*(.+)')
>>          self.completed_re = re.compile (r'.* completed at (.*)')
>>          # Pieces of text to write at the head of the output.
>>          # start_line is a pair in which the first element is a datetime
> Tested that with four runs on powerpc64-linux, four configs each time;
> test-summary
> shows the same in all cases.  Many lines have moved compared to without
> the patch, but that cannot be helped.  Okay for mainline?
> 2014-09-19  Segher Boessenkool  <>
> contrib/
> 	* (Prog.result_re): Include options in test name.

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:

  # Ugly hack for gfortran.dg/dg.exp
  if ("$TOOL" == "gfortran" && testname ~ /^gfortran.dg\/g77\//)

(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.

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.


More information about the Gcc-patches mailing list