This is the mail archive of the gcc-patches@gcc.gnu.org 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: Testsuite / Cilk Plus: Include library path in compile flags in gcc.dg/cilk-plus/cilk-plus.exp


Hi!

On Mon, Nov 04, 2013 at 11:02:13PM +0000, Iyer, Balaji V wrote:

See my other mail on this topic, the number of different option combinations
is just excessive and must be reduced to a reasonable minimum.

> 2). The C tests are extremely time-consuming (m32/m64) with NO -jxx on the c/l:
> 
>   x86_64-linux (32 cores 2.8G Xeon) : 36m/421m/6m
>   x86_64-darwin12 (8 cores 2.8G Xeon) : 45m/309m/2m.
> 
> c.f. the g++ tests which take ~2m wall clock.
> 
> BVI: yes, I know about this. It is because some of the Cilk tests are run for higher iterations to make it force a steal. This is one of the main place were runtime bugs could occur. My original solution was to put them all in separate directories with separate scripts to run them, but someone in GCC community did not like that idea. This way, when people compile with -jN, they will be run in parallel. If that is a good idea, I can look into reorganizing them. 
> 
> this might be nothing to do with cilk, but it certainly warrants investigation.

Tests that many seconds or more on fast machines, especially if you run them
25 times, are simply not appropriate for gcc testsuite, at least not by
default.  We have run_expensive_tests (from GCC_RUN_EXPENSIVE_TESTS in
environment), which can be used say for:
/* { dg-additional-options "-DEXPENSIVE" { target run_expensive_tests } } */
or
// { dg-additional-options "-DASAN_AVOID_EXPENSIVE_TESTS=1" { target { ! run_expensive_tests } } }
or
/* { dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O2" } } */
(just grep for it), but still it shouldn't be prohibitively slow.
Remember what is slow on fast machines might turn into days on really slow
machines.  Say, if all you are looking for is look for library
synchronization issues, I guess all optimization levels still result in
similar pattern of library calls, so even for run_expensive_tests you could
use higher iteration count for a single optimization level (say -O2)
and for all others just use smaller iteration count.

	Jakub


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