hi Balaji sorry for a short reply, but I'm traveling this week,
On 4 Nov 2013, at 23:02, Iyer, Balaji V wrote: > 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 > reorganising them. total CPU time consumed is relevant - folks can already get parallel testing (different suites for different languages will run in parallel). However, GCC is tested on a wide variety of hardware, e.g. even I use from core duo - 32core x86_64. There are facilities to identify tests as "expensive" - and testing that might add hundreds of minutes to the cycle would come into that category (at least, IMO). There should be some way to "opt in" if the tests are specifically of interest. sorry again for brevity, Iain
