On Tue, Nov 05, 2013 at 12:21:04PM +0100, Jakub Jelinek wrote:
> 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.
Oh, another thing, runtime tests should abort () or __builtin_abort () on
failure, rather then just exit with non-zero status.
Also, I wonder about the fib_* tests, fib_serial calls fib rather than
fib_serial, so effectively the only difference between calling fib_serial
and fib is just the outermost iteration. Also, are you really sure you have
to call fib with all values from 0 up to 40? Isn't it enough to just call
fib (40) once and compare that with precomputed fib (40) number?
Because, when a single test takes about 2 minutes to run, it is really too
much, and very much unnecessarily so.
Jakub
