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.
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 t...@codesourcery.com
*
On Nov 25, 2014, at 12:15 PM, Jakub Jelinek ja...@redhat.com 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
Hi Jakub,
On 15 September 2014 18:05, Jakub Jelinek ja...@redhat.com 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
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,
skip
On 10 October 2014 16:19, Jakub Jelinek ja...@redhat.com 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
On Fri, Oct 10, 2014 at 04:50:47PM +0200, Christophe Lyon wrote:
On 10 October 2014 16:19, Jakub Jelinek ja...@redhat.com 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:
==
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
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
in that
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
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 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 a
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 add some
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 what they
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.
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 e.g.
On Mon, Sep 15, 2014 at 7:44 PM, Mike Stump mikest...@comcast.net wrote:
On Sep 15, 2014, at 9:05 AM, Jakub Jelinek ja...@redhat.com 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),
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 Tue, Sep 16, 2014 at 11:28 AM, Jakub Jelinek ja...@redhat.com 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
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, box,
On Fri, Sep 12, 2014 at 04:42:25PM -0700, Mike Stump wrote:
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek ja...@redhat.com 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,
On Sep 15, 2014, at 9:05 AM, Jakub Jelinek ja...@redhat.com 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
On 12 September 2014 19:46:33 Mike Stump mikest...@comcast.net wrote:
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek ja...@redhat.com 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
On 13 September 2014 02:04:51 Jakub Jelinek ja...@redhat.com 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
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
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
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 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
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 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 means that any
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek ja...@redhat.com 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)
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 ja...@redhat.com 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
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
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
check
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 be
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
Jakub == Jakub Jelinek ja...@redhat.com 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
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
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 ~10m
check
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.
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 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
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 11 September 2014 20:19:31 Jakub Jelinek ja...@redhat.com 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
On Thu, Sep 11, 2014 at 11:24:08PM +0200, Bernhard Reutner-Fischer wrote:
On 11 September 2014 20:19:31 Jakub Jelinek ja...@redhat.com 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
On Sep 11, 2014, at 3:15 PM, Jakub Jelinek ja...@redhat.com 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 _ _
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, what about
On Sep 10, 2014, at 7:16 AM, Jakub Jelinek ja...@redhat.com wrote:
IMHO the best fix for that is following, use the same predicate whether to
run the vect-args.c tests or not as is used for all other tests.
Ok for trunk?
Looks suspiciously looks familiar. Ok. Thanks.
On Sep 9, 2014, at 8:14 AM, VandeVondele Joost joost.vandevond...@mat.ethz.ch
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
On Wed, 2014-09-10 at 11:19 -0700, Mike Stump wrote:
On Sep 9, 2014, at 8:14 AM, VandeVondele Joost
joost.vandevond...@mat.ethz.ch 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
On Sep 10, 2014, at 1:38 PM, David Malcolm dmalc...@redhat.com 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, 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 set
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 related to
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
On Sep 10, 2014, at 2:23 PM, Jakub Jelinek ja...@redhat.com wrote:
Seems file mkdir in tcl doesn't error on pre-existing directory,
shell mkdir will. :-)
56 matches
Mail list logo
