This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: parallel check output changes?

On Thu, Oct 02, 2014 at 06:46:19PM +0100, Richard Sandiford wrote:
> Segher Boessenkool <> writes:
> > On Wed, Sep 24, 2014 at 10:54:57AM -0400, Andrew MacLeod wrote:
> >> Is this suppose to be resolved now?  I'm still seeing some issues with a 
> >> branch cut from mainline from yesterday.
> >
> > Confirmed.  The following patch works for me, and Andrew has tested it
> > as well.  The comment it removes isn't valid before the patch either.
> I get the impression from a short dismissal like that that this script
> is pretty hated :-(.  Remember that originally the script was trying to

No, it is certainly appreciated that it speeded up the processing.

> make the result of combining separate .sum files the same as the .sum
> file you'd get for -j1.  As Jakub said upthread, that's a lost cause
> with the new approach to parallel testing, but I think the comment was
> valid while matching -j1 was still a goal.

I'm sorry for invalidating those assumptions.  Indeed, before my recent
changes, all tests for the same testcase name were run serially by the same
job.  If we wanted to preserve that property, we could e.g. store the
results of gcc_parallel_test_run_p in some tcl array with testcase as the
key, and after the
        if { $gcc_runtest_parallelize_enable == 0 } {
            return 1
test add a test if we've been asked about a particular testcase already,
just return what we've returned before.  Perhaps accompany that with
lowering the granularity (e.g. from 10 to 5).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]