On Nov 25, 2014, at 12:15 PM, Jakub Jelinek wrote:
> On Tue, Nov 25, 2014 at 03:27:40PM +0100, Tom de Vries wrote:
>> This patch fixes that by ensuring that we print that unsupported message
>> only once.
>>
>> The resulting test result comparison diff is:
>> 2014-11-25 Tom de Vries
>>
>>
On Tue, Nov 25, 2014 at 03:27:40PM +0100, Tom de Vries wrote:
> This patch fixes that by ensuring that we print that unsupported message only
> once.
>
> The resulting test result comparison diff is:
> 2014-11-25 Tom de Vries
>
> * testsuite/libstdc++-prettyprinters/prettyprinters.exp:
On 15-09-14 18:05, Jakub Jelinek wrote:
libstdc++-v3/
* testsuite/Makefile.am (check_p_numbers0, check_p_numbers1,
check_p_numbers2, check_p_numbers3, check_p_numbers4,
check_p_numbers5, check_p_numbers6, check_p_numbers,
check_p_subdirs): New variables.
(c
On Fri, Oct 10, 2014 at 04:50:47PM +0200, Christophe Lyon wrote:
> On 10 October 2014 16:19, Jakub Jelinek wrote:
> > On Fri, Oct 10, 2014 at 04:09:39PM +0200, Christophe Lyon wrote:
> >> my.exp contains the following construct which is often used in the
> >> testsuite:
> >> ==
> >> forea
On 10 October 2014 16:19, Jakub Jelinek wrote:
> On Fri, Oct 10, 2014 at 04:09:39PM +0200, Christophe Lyon wrote:
>> my.exp contains the following construct which is often used in the testsuite:
>> ==
>> foreach src [lsort [glob -nocomplain $srcdir/$subdir/*.c]] {
>> # If we're only te
On Fri, Oct 10, 2014 at 04:09:39PM +0200, Christophe Lyon wrote:
> my.exp contains the following construct which is often used in the testsuite:
> ==
> foreach src [lsort [glob -nocomplain $srcdir/$subdir/*.c]] {
> # If we're only testing specific files and this isn't one of them,
> ski
Hi Jakub,
On 15 September 2014 18:05, Jakub Jelinek wrote:
[...]
> # For parallelized check-% targets, this decides whether parallelization
> # is desirable (if -jN is used and RUNTESTFLAGS doesn't contain anything
> # but optional --target_board or --extra_opts arguments). If desirable,
>
On Mon, Sep 22, 2014 at 12:21:08PM -0400, Jason Merrill wrote:
> On 09/22/2014 11:58 AM, Jakub Jelinek wrote:
> >LGTM (though, supposedly we want similar change in
> >libstdc++-v3/testsuite/Makefile.am).
> >Or, if people would really like to see the commands, we could print them
> >just once, using
On 09/22/2014 11:58 AM, Jakub Jelinek wrote:
LGTM (though, supposedly we want similar change in
libstdc++-v3/testsuite/Makefile.am).
Or, if people would really like to see the commands, we could print them
just once, using e.g.
-$(if $(check_p_subno),@)(rootme= ...
(then e.g. check-parall
On Mon, Sep 22, 2014 at 05:49:12PM +0200, Jakub Jelinek wrote:
> On Mon, Sep 22, 2014 at 10:44:06AM -0500, Segher Boessenkool wrote:
> > On Mon, Sep 22, 2014 at 05:26:04PM +0200, Jakub Jelinek wrote:
> > > I've been considering that too, but not sure what info people find
> > > valuable
> > > and
On Mon, Sep 22, 2014 at 11:43:35AM -0400, Jason Merrill wrote:
> On 09/22/2014 11:26 AM, Jakub Jelinek wrote:
> >On Mon, Sep 22, 2014 at 11:21:14AM -0400, Jason Merrill wrote:
> >>If I say 'rgt dg.exp=var-templ1.C' the actual test results are lost in the
> >>explosion of shell verbosity. Could we
On Mon, Sep 22, 2014 at 10:44:06AM -0500, Segher Boessenkool wrote:
> On Mon, Sep 22, 2014 at 05:26:04PM +0200, Jakub Jelinek wrote:
> > I've been considering that too, but not sure what info people find valuable
> > and what they don't.
>
> The ten million "Running blablablalba.exp ..." messages
On Mon, Sep 22, 2014 at 05:26:04PM +0200, Jakub Jelinek wrote:
> I've been considering that too, but not sure what info people find valuable
> and what they don't.
The ten million "Running blablablalba.exp ..." messages on a very parallel
run aren't helpful in my opinion. There might be more but
On 09/22/2014 11:26 AM, Jakub Jelinek wrote:
On Mon, Sep 22, 2014 at 11:21:14AM -0400, Jason Merrill wrote:
If I say 'rgt dg.exp=var-templ1.C' the actual test results are lost in the
explosion of shell verbosity. Could we add some '@'s to more of the rules,
perhaps?
I've been considering that
On Mon, Sep 22, 2014 at 11:21:14AM -0400, Jason Merrill wrote:
> On 09/12/2014 08:04 PM, Jakub Jelinek wrote:
> >I've been worried about the quick cases where
> >parallelization is not beneficial, like make check-gcc \
> >RUNTESTFLAGS=dg.exp=pr60123.c or similar, but one doesn't usually pass -jN
>
On 09/12/2014 08:04 PM, Jakub Jelinek wrote:
I've been worried about the quick cases where
parallelization is not beneficial, like make check-gcc \
RUNTESTFLAGS=dg.exp=pr60123.c or similar, but one doesn't usually pass -jN
in that case.
I have -jN in my $MAKEFLAGS, so I've been running into thi
>> > These numbers are useful to try and ensure the overhead (scaling factor)
>> > is reasonable, thanks.
>>
>> A nice improvement indeed. The patched result is 15 times faster
>> than the serial unpatched run. So there is room for improvement
>
> Note, the box used was oldish AMD 16-core, no ht
On Tue, Sep 16, 2014 at 11:28 AM, Jakub Jelinek wrote:
> On Tue, Sep 16, 2014 at 11:20:37AM +0200, Richard Biener wrote:
>> > This confuses me, but, no matter. Isn’t 8hrs time data? :-)
>
> It is, but not time(1) data, just wall clock computed from subtracting
> mtimes of my make check output lo
On Tue, Sep 16, 2014 at 11:20:37AM +0200, Richard Biener wrote:
> > This confuses me, but, no matter. Isn’t 8hrs time data? :-)
It is, but not time(1) data, just wall clock computed from subtracting
mtimes of my make check output log and make -j48 bootstrap log.
> >> patch toplevel make -j48 -k
On Mon, Sep 15, 2014 at 7:44 PM, Mike Stump wrote:
> On Sep 15, 2014, at 9:05 AM, Jakub Jelinek wrote:
>
> All the updates sound good.
>
>> Regtested on x86_64-linux, without the patch toplevel make -k check
>> took 8hrs3minutes (don't have time data for that run),
>
> This confuses me, but, no m
On Sep 15, 2014, at 9:05 AM, Jakub Jelinek wrote:
All the updates sound good.
> Regtested on x86_64-linux, without the patch toplevel make -k check
> took 8hrs3minutes (don't have time data for that run),
This confuses me, but, no matter. Isn’t 8hrs time data? :-)
> patch toplevel make -j48
On Fri, Sep 12, 2014 at 04:42:25PM -0700, Mike Stump wrote:
> On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote:
> > Here is my latest version of the patch.
>
> I did a timing test:
Here is an updated version.
Changes since last version:
1) acats parallelized the same way (just, because it is in
On 13 September 2014 02:04:51 Jakub Jelinek wrote:
On Fri, Sep 12, 2014 at 04:42:25PM -0700, Mike Stump wrote:
> curious, when I run atomic.exp=stdatom\*.c:
>
> gcc.dg/atomic/atomic.exp completed in 30 seconds.
>
> atomic.exp=c\*.c takes 522 seconds with 3, 2, 5 and 4 being the worst
offende
On 12 September 2014 19:46:33 Mike Stump wrote:
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote:
> Here is my latest version of the patch.
>
> With this patch I get identical test_summary output on make -k check
> (completely serial testing) and make -j48 -k check from toplevel directory.
>
>
On Fri, Sep 12, 2014 at 04:42:25PM -0700, Mike Stump wrote:
> curious, when I run atomic.exp=stdatom\*.c:
>
> gcc.dg/atomic/atomic.exp completed in 30 seconds.
>
> atomic.exp=c\*.c takes 522 seconds with 3, 2, 5 and 4 being the worst
> offenders.
That's the
@if [ -z "$(filter-out --ta
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote:
> Here is my latest version of the patch.
I did a timing test:
Before:
real0m57.198s
user1m24.736s
sys 0m19.816s
after:
real0m28.224s
user1m27.823s
sys 0m22.374s
This is a -j70 run on a 64 core power7 of check-objc, I
> So, I’d love to see the numbers for 5 and 20 to double check that 10 is the
> right number to pick. This sort of refinement is trivial post checkin.
So, some timings with the patch, I think this is great.
Doing the testing you suggest, changing the variable doesn't influence things
much (at
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote:
> Here is my latest version of the patch.
>
> With this patch I get identical test_summary output on make -k check
> (completely serial testing) and make -j48 -k check from toplevel directory.
>
> Major changes since last version:
> 1) I've chang
On Fri, Sep 12, 2014 at 04:36:05PM +, VandeVondele Joost wrote:
>
>
> >> Regtested on x86_64-linux, ok for trunk?
> >
> >Oh, forgot to say, PR56408 isn't fixed by this patch, but given the
> >higher granularity (10 tests instead of 1) we don't happen to trigger it
> >right now.
>
> which me
>> Regtested on x86_64-linux, ok for trunk?
>
>Oh, forgot to say, PR56408 isn't fixed by this patch, but given the
>higher granularity (10 tests instead of 1) we don't happen to trigger it
>right now.
which means that any commit to that dir could trigger it, right ?
On Fri, Sep 12, 2014 at 06:32:41PM +0200, Jakub Jelinek wrote:
> Regtested on x86_64-linux, ok for trunk?
Oh, forgot to say, PR56408 isn't fixed by this patch, but given the
higher granularity (10 tests instead of 1) we don't happen to trigger it
right now.
Jakub
On Fri, Sep 12, 2014 at 09:47:00AM +, VandeVondele Joost wrote:
> Obviously, if Jakub's patch can be made to work around the testsuite
> special cases, I believe it should be superior. If not, the attached
> patch is working as far as I can tell, and provides a significant
> improvement over
On 12/09/14 09:47 +, VandeVondele Joost wrote:
a newer patch (v8) I'll send soon
attached with updated changelog. Compared to the previously posted v6, only the
libstdc++-v3/testsuite/Makefile.am has been refined to split a little more the
e*/* pattern, and two quickly running goal have
> a newer patch (v8) I'll send soon
attached with updated changelog. Compared to the previously posted v6, only the
libstdc++-v3/testsuite/Makefile.am has been refined to split a little more the
e*/* pattern, and two quickly running goal have been merged, in addition to
fixing the pre-exisiting
>>> >For PR56408 we need some fix.
>> BTW, is there anything special about Fortran ? There are at least 180 test
>> files that contain 'dg-additional-sources' >some in a very non-local way:
>The current scheme comes at its limits in that case. . See the files listed in
>the PR for issues.
So, w
On Sep 11, 2014, at 3:15 PM, Jakub Jelinek wrote:
> That is news to me, but given the amount of test -a/-o uses e.g. in
> gcc/configure and hundreds of places, I'd say what we care is what is more
> portable to old shells.
No, we can’t care about that. If that were true, the _ && _ in the compil
On Thu, Sep 11, 2014 at 11:24:08PM +0200, Bernhard Reutner-Fischer wrote:
> On 11 September 2014 20:19:31 Jakub Jelinek wrote:
>
> >On Thu, Sep 11, 2014 at 07:26:37PM +0200, Jakub Jelinek wrote:
> >> right now. The patch below intends to serialize the content of the
> >> problematic *.exp tests
On 11 September 2014 20:19:31 Jakub Jelinek wrote:
On Thu, Sep 11, 2014 at 07:26:37PM +0200, Jakub Jelinek wrote:
> right now. The patch below intends to serialize the content of the
> problematic *.exp tests (the first runtest to reach one of those will simply
> run all the tests from that *.
On 11.09.2014 20:33, VandeVondele Joost wrote:
>For PR56408 we need some fix.
BTW, is there anything special about Fortran ? There are at least 180 test
files that contain 'dg-additional-sources' some in a very non-local way:
Well, the question is what you want to do with the different files.
On Thu, Sep 11, 2014 at 06:33:27PM +, VandeVondele Joost wrote:
> > And these Fortran inter-test dependencies, which Tobias told me is
> > PR56408.
> > For PR56408 we need some fix.
>
> BTW, is there anything special about Fortran ? There are at least 180 test
> files that contain 'dg-additi
> And these Fortran inter-test dependencies, which Tobias told me is
> PR56408.
> For PR56408 we need some fix.
BTW, is there anything special about Fortran ? There are at least 180 test
files that contain 'dg-additional-sources' some in a very non-local way:
./objc.dg/foreach-2.m: /* {
On Thu, Sep 11, 2014 at 07:26:37PM +0200, Jakub Jelinek wrote:
> right now. The patch below intends to serialize the content of the
> problematic *.exp tests (the first runtest to reach one of those will simply
> run all the tests from that *.exp file, others will skip it).
Forgotten patch below.
On Thu, Sep 11, 2014 at 05:04:56PM +, VandeVondele Joost wrote:
> > Here is a patch I'm testing now:
>
> I also tested your patch to compare timings vs a newer patch (v8) I'll send
> soon
>
> == patch v8 == make -j32 -k ==
> check-fortran 4m58.178s
> check-c++ ~10m
> check-c ~10
> Here is a patch I'm testing now:
Hi Jakub,
I also tested your patch to compare timings vs a newer patch (v8) I'll send soon
== patch v8 == make -j32 -k ==
check-fortran 4m58.178s
check-c++ ~10m
check-c ~10m
check 15m29.873s
== patch Jakub
check-c++ ~20m
check-fortran
> "Jakub" == Jakub Jelinek writes:
Jakub> I fear that is going to be too expensive, because e.g. all the
Jakub> caching that dejagnu and our tcl stuff does would be gone, all
Jakub> the tests for lp64 etc. would need to be repeated for each test.
In gdb I arranged to have this stuff saved i
On Thu, Sep 11, 2014 at 10:06:40AM +0200, Jakub Jelinek wrote:
> There is an option to touch say *-parallel/finished file once any of the
> check-parallel-gcc-{1,2,...} goals is done (because when it finishes, it
> means all the tests for the particular check-$lang that are parallelizable
> have ei
On Thu, Sep 11, 2014 at 09:51:23AM +0200, Jakub Jelinek wrote:
> I can't find how to query the -jN value passed to make check by the user
> though, both $(MFLAGS) and $(MAKEFLAGS) only contain something like
> --jobserver-fds=3,5 -j from which it is not possible to find out how many
> goals would b
On Wed, Sep 10, 2014 at 11:23:34PM +0200, Jakub Jelinek wrote:
> On Wed, Sep 10, 2014 at 11:08:22PM +0200, Jakub Jelinek wrote:
> > Perhaps better approach might be if we have some way how to synchronize
> > among
> > multiple expect processes and spawn only as many expects (of course, per
> > che
On Sep 10, 2014, at 2:23 PM, Jakub Jelinek wrote:
> Seems file mkdir in tcl doesn't error on pre-existing directory,
shell mkdir will. :-)
On Wed, Sep 10, 2014 at 11:08:22PM +0200, Jakub Jelinek wrote:
> Perhaps better approach might be if we have some way how to synchronize among
> multiple expect processes and spawn only as many expects (of course, per
> check target) as there are CPUs. E.g. if mkdir is atomic on all
> hosts/filesy
On Wed, Sep 10, 2014 at 04:38:32PM -0400, David Malcolm wrote:
> > So when last I played in this area, I wanted a command line tool that
> > would bin-pack from the command line. I would then grab the seconds
> > per for each .exp, and bin pack to the fixed N, where N was the core
> > count or rel
On Wed, 10 Sep 2014, David Malcolm wrote:
> (A) test discovery; write out a fine-grained Makefile in which *every*
> testcase is its own make target (to the extreme limit of
> parallelizability e.g. on the per-input-file level)
The DejaGnu design doesn't allow test discovery in general (as the se
On Sep 10, 2014, at 1:38 PM, David Malcolm wrote:
> Perhaps this is a silly question, but has anyone tried going the whole
> way and not having buckets, going to an extremely fine-grained approach
No, we fear the overhead, but do not know what it is.
On Wed, 2014-09-10 at 11:19 -0700, Mike Stump wrote:
> On Sep 9, 2014, at 8:14 AM, VandeVondele Joost
> wrote:
> > Attached is a further revision of the patch, now dealing with
> check-c++.
>
> So when last I played in this area, I wanted a command line tool that
> would bin-pack from the command
On Sep 9, 2014, at 8:14 AM, VandeVondele Joost
wrote:
> Attached is a further revision of the patch, now dealing with check-c++.
So when last I played in this area, I wanted a command line tool that would
bin-pack from the command line. I would then grab the seconds per for each
.exp, and bin
55 matches
Mail list logo
