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 11 September 2014 15:45, VandeVondele Joost
wrote:
>
>>> could it be that the pattern in normal1 should have been '[ab]*/ de*/
>>> [ep]*/*' ?
>>
>>Yes, we are running these tests multiple times:
>>
>>PASS: 23_containers/map/modifiers/erase/abi_tag.cc (test for excess errors)
>>PASS: 23_contai
>> could it be that the pattern in normal1 should have been '[ab]*/ de*/
>> [ep]*/*' ?
>
>Yes, we are running these tests multiple times:
>
>PASS: 23_containers/map/modifiers/erase/abi_tag.cc (test for excess errors)
>PASS: 23_containers/multimap/modifiers/erase/abi_tag.cc (test for excess
>erro
On 11 September 2014 07:22, VandeVondele Joost wrote:
> Jakub,
>
>> First of all, the -j2 testing shows more tests tested in gcc and libstdc++:
>>
>>-# of expected passes 10133
>>+# of expected passes 10152
>>
>>+PASS: 23_containers/set/modifiers/erase/abi_tag.cc (test for exce
> could it be that the pattern in normal1 should have been '[ab]*/ de*/
> [ep]*/*' ?
I've checked that this fixes the bug in the current trunk split. I.e. files are
stil tested, but now only once. Consider this change added to the previously
submitted patch.
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
Jakub,
> First of all, the -j2 testing shows more tests tested in gcc and libstdc++:
>
>-# of expected passes 10133
>+# of expected passes 10152
>
>+PASS: 23_containers/set/modifiers/erase/abi_tag.cc (test for excess errors)
>[...]
>
>Not sure where the bug is, could be e.g. in
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
> You mean enhancing the script to split across arbitrarily long prefixes?
> That would be great.
I've now a script that does something like that:
~/test$ find /data/vjoost/gnu/gcc_trunk/gcc/gcc/testsuite/gfortran.dg/
-maxdepth 1 -type f -printf "%f\n" | ./generate_patterns.py 500 foo
All 3947
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
Thanks for testing.
The vect-args.c I explained earlier, and is indeed due to i386.exp hardcoding
those.
The libstdc++ double counts didn't appear in my testing, but I'll have a look.
Note that these patterns are handwritten, so error prone.
The long tests in libstdc++ come from (in timing o
On Tue, Sep 09, 2014 at 03:14:08PM +, VandeVondele Joost wrote:
> Attached is a further revision of the patch, now dealing with check-c++.
> Roughly 50% speedup here at '-j32' (18m vs 12m). For my setup
> (--enable-languages=c,c++,fortran) I have now improved all targets called in
> 'make -
Attached is a further revision of the patch, now dealing with check-c++.
Roughly 50% speedup here at '-j32' (18m vs 12m). For my setup
(--enable-languages=c,c++,fortran) I have now improved all targets called in
'make -j32 -k check'. The latter is now 30% faster (15m vs 20m). Note that
there ar
Now with gzipped figure.. why do these bounce ?
> But if there are jobs that just take 1s to complete, then clearly it doesn't
> make sense to split them off as separate job. I think we don't need 100%
> even split, but at least roughly is highly desirable.
Let me add some data, attached is a gr
On 09/09/2014 06:33 PM, Jakub Jelinek wrote:
On Tue, Sep 09, 2014 at 06:27:10PM +0400, Yury Gribov wrote:
On 09/09/2014 06:14 PM, VandeVondele Joost wrote:
I certainly don't want to claim that the patch I have now is perfect,
it is rather an incremental improvement on the current setup.
I'd s
On Tue, Sep 09, 2014 at 06:27:10PM +0400, Yury Gribov wrote:
> On 09/09/2014 06:14 PM, VandeVondele Joost wrote:
> >I certainly don't want to claim that the patch I have now is perfect,
> >it is rather an incremental improvement on the current setup.
>
> I'd second this. Writing patterns manually
On 09/09/2014 06:14 PM, VandeVondele Joost wrote:
I certainly don't want to claim that the patch I have now is perfect,
it is rather an incremental improvement on the current setup.
I'd second this. Writing patterns manually seems rather inefficient and
error-prone
(not undoable of course but
> If you get whitespace right, one can provide multiple different wildcards to
> a single *.exp file, e.g.
> make check-gcc RUNTESTFLAGS="dg.exp='p[0-9A-Za-qs-z]* pr[9A-Za-z]*'" should
> cover all tests starting with p other than pr[0-8]*.c (where you could split
> say pr[0-2]* into another job, pr
On Tue, Sep 09, 2014 at 10:57:09AM +, VandeVondele Joost wrote:
> > No. As I wrote earlier, splitting on filenames and test counts only is only
> > very rough split, all the splits really need to be backed out by real timing
> > data from popular targets.
>
> Furthermore, for parallel perf
> No. As I wrote earlier, splitting on filenames and test counts only is only
> very rough split, all the splits really need to be backed out by real timing
> data from popular targets.
I'm actually doing quite some testing trying to get a reasonable balance,
checking 'completed in' in all *.l
> +# ls -1 | ../../../contrib/generate_tcl_patterns.sh 300
> "dg.exp=gfortran.dg/"
>
> How does this work with subdirectories? Can we replace ls with find?
The input to the script is general, you can use this to your advantage. For
example, I've been using:
ls -1 g++.*/* | cut -c5- | ../../.
On Tue, Sep 09, 2014 at 02:02:18PM +0400, Yury Gribov wrote:
> On 09/09/2014 10:51 AM, VandeVondele Joost wrote:
> > Attached is an extended version of the patch,
> > it brings a 100% improvement in make -j32 -k check-gcc
>
> First of all, many thanks for working on this.
>
> +# ls -1 | ../../.
On 09/09/2014 10:51 AM, VandeVondele Joost wrote:
> Attached is an extended version of the patch,
> it brings a 100% improvement in make -j32 -k check-gcc
First of all, many thanks for working on this.
+# ls -1 | ../../../contrib/generate_tcl_patterns.sh 300
"dg.exp=gfortran.dg/"
How does t
Attached is an extended version of the patch, it brings a 100% improvement in
make -j32 -k check-gcc (down from 20min to <10min) by modification of
check_gcc_parallelize.
It includes one non-trivial part, namely a split of the target exps. They are
now all split using a common choice (based on
>> > Please sort the letters (LC_ALL=C sort) and where consecutive, use ranges.
>> > Thus \[0-9A-Zhjqvx-z\]*
OK, works fine with the attached patch, and looks cleaner in Make-lang.in.
Now, with the proper email address for gcc-patches... I wonder how many time
I'll be punished for typos.
unmodi
On Fri, Sep 05, 2014 at 02:48:01PM +, VandeVondele Joost wrote:
>
> > Please sort the letters (LC_ALL=C sort) and where consecutive, use ranges.
> > Thus \[0-9A-Zhjqvx-z\]* or so. What is - doing in your list? _-9 is quite
> > unexpected range.
>
> the '-' is a bug indeed. I added this t
On Fri, Sep 05, 2014 at 02:26:45PM +, VandeVondele Joost wrote:
> Adding label: mu matching files:278
> Adding label: wlgo matching files:284
> Adding label: vhzPkqWx_-9876543210ZYXVUTSRQONMLKJIHGFEDCBAyj matching
> files:94
> patterns:
> dg.exp=gfortran.dg/p* \
> dg.exp=gfortran.dg/c* \
>
> The splits are in the Makefiles, see check_gcc_parallelize
attached is a patch to improve the parallel performance of 'make -jXX -k
check-fortran'. For XX=16, this yields ~50% speedup, and even with XX=4 we
still have 15%, the measured slowdown at XX=1 (<2%) is in the noise of testing.
The pa
On Wed, Sep 03, 2014 at 10:35:41AM +, VandeVondele Joost wrote:
> >> expect -- /usr/share/dejagnu/runtest.exp --tool gcc lto.exp weak.exp
> >> tls.exp ipa.exp tree-ssa.exp debug.exp >dwarf2.exp fixed-point.exp
> >> vxworks.exp cilk-plus.exp vmx.exp pch.exp simulate-thread.exp
> >> x86_64-co
>> expect -- /usr/share/dejagnu/runtest.exp --tool gcc lto.exp weak.exp tls.exp
>> ipa.exp tree-ssa.exp debug.exp >dwarf2.exp fixed-point.exp vxworks.exp
>> cilk-plus.exp vmx.exp pch.exp simulate-thread.exp x86_64-costmodel-vect.exp
>> i386-costmodel-vect.exp spu-costmodel-vect.exp ppc-costmodel
> I have to admit that I don't know why that's the case.
Actually Marc answered that one (I had the wrong mail address for gcc@ so
repeat here):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155
> See: gcc/fortran/Make-lang.in, which has:
I'll have a look and do some testing what the gains/co
Hi Joost,
VandeVondele Joost wrote:
> I've noticed that
> make -j -k check-fortran
> results in a serialized checking, while
> make -j32 -k check-fortran
> goes parallel.
I have to admit that I don't know why that's the case. However, I can answer
the next question, is presumably related to thi
On Wed, Sep 03, 2014 at 09:37:19AM +, VandeVondele Joost wrote:
> > It is intentional. With -j it is essentially a fork bomb, just don't use
> > it.
>
> well, silently ignoring it for just this target did cost me a lot of time,
> while an eventual fork bomb would have been dealt with much
> What did you expect for -j alone? an error?
No, as is standard in gnu make, a new process for any target that can be
processed (i.e. unlimited).
>> ... check-fortran seems to be limited to about ~5 parallel targets ...
>
>Running the make with -j8 gives 7 directories gfortran[1-6]? in gcc/tes
> It is intentional. With -j it is essentially a fork bomb, just don't use it.
well, silently ignoring it for just this target did cost me a lot of time,
while an eventual fork bomb would have been dealt with much more quickly.
>> Somewhat related is there a rule of thumb on how is the gran
On Wed, Sep 03, 2014 at 09:15:51AM +, VandeVondele Joost wrote:
> I've noticed that
>
> make -j -k check-fortran
>
> results in a serialized checking, while
>
> make -j32 -k check-fortran
>
> goes parallel. Somehow the explicit 'N' in -jN seems to be needed for the
> check target, while th
On Wed, 3 Sep 2014, VandeVondele Joost wrote:
I've noticed that
make -j -k check-fortran
results in a serialized checking, while
make -j32 -k check-fortran
goes parallel. Somehow the explicit 'N' in -jN seems to be needed for the check
target, while the other targets seem to do just fine.
I've noticed that
make -j -k check-fortran
results in a serialized checking, while
make -j32 -k check-fortran
goes parallel. Somehow the explicit 'N' in -jN seems to be needed for the check
target, while the other targets seem to do just fine. Is that a feature, or
should I file a PR for that
89 matches
Mail list logo
