------- Comment #13 from rob1weld at aol dot com 2007-06-19 17:11 -------
>>The goal of the tests is not to measure some time, but to check that
>>intervals are properly ordered, i.e., t1<=dat1<=t1a and t2a<=dat2-dat1<= t2.
If that is the "goal" then could we eliminate all influence of time (midnight /
leap seconds / end of year, and whatever random issues occur) by using a
procedure similar to what is described in:
gcc-4_3-trunk/libmudflap/testsuite/lib/mfdg.exp ?
# Indicate that this test case is to be rerun several times. This
# is useful if it is nondeterministic. This applies to rerunning the
# test program only, not rebuilding it.
# The embedded format is "{ dg-repetitions N }", where N is the number
# of repetitions. It better be greater than zero.
#
proc dg-repetitions { line value } {
upvar dg-repetitions repetitions
set repetitions $value
}
#
# Indicate that this test case is to be run with a short timeout.
# The embedded format is "{ dg-timeout N }", where N is in seconds.
#
proc dg-timeout { line value } {
global dg-timeout
set dg-timeout $value
}
# dejagnu's config/unix.exp hard-codes 300 seconds as the timeout
# for any natively run executable. That's too long for tests run
# multiple times and that may possibly hang. So we override it here
# to provide some degree of control.
We could run the test 5 times and if we got at least one pass we could write
"PASS:" and use "WARNING:" to write the number of failures. If we get 5
failures then we just write "FAIL:".
The last time I ran "make -i check" I got a pass on this test, the time before
a fail; previously it's been hit and miss. The above technique will catch
random failures better and avoid false positives.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057
