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