Patchwork [testsuite] Skip long-running tests by default

login
register
mail settings
Submitter Rainer Orth
Date Aug. 30, 2010, 4:17 p.m.
Message ID <yddocckkrc6.fsf@manam.CeBiTec.Uni-Bielefeld.DE>
Download mbox | patch
Permalink /patch/63070/
State New
Headers show

Comments

Rainer Orth - Aug. 30, 2010, 4:17 p.m.
This is a follow-up to the discussion in

	[testsuite] Increase gcc.dg/pr43058.c timeout
	http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01162.html

Instead of moving long-running tests to a separate testsuite (which
would have to deal with at least C, C++, and Fortran tests), I've
decided to make use of the effective-target mechanism to tag a testcase
as CPU hog and avoid running it by default.

I'm tagging hogs with dg-require-effective-target run_cpuhogs; tests so
tagged are only run if the RUN_CPUHOGS environment variable is
non-empty, so if testers decide they want to spend the CPU cycles, they
are free to do so :-)

For the moment, I'm only tagging limits-fnargs.c, the worst offender by
far, but others could be added if desired.

Tested with the appropriate runtest invocation both with and without
RUN_CPUHOGS set on i386-pc-solaris2.11.

Ok for mainline, 4.4 and 4.5 branches?

	Rainer


2010-08-29  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	gcc:
	* doc/sourcebuild.texi (Effective-Target Keywords): Document
	run_cpuhogs.

	gcc/testsuite:
	* lib/target-supports.exp (check_effective_target_run_cpuhogs):
	New proc.
	* gcc.c-torture/compile/limits-fnargs.c: Use
	dg-require-effective-target run_cpuhogs.
Mike Stump - Aug. 30, 2010, 4:45 p.m.
On Aug 30, 2010, at 9:17 AM, Rainer Orth wrote:
> Instead of moving long-running tests to a separate testsuite (which
> would have to deal with at least C, C++, and Fortran tests), I've
> decided to make use of the effective-target mechanism to tag a testcase
> as CPU hog and avoid running it by default.

I think this is a nice solution, the testcase names remain stable over the years, it's easy to maintain, less invasive than moving testcases around...  the only possible change might be if we wanted to tag each with some metric of the expected goodness v run time or to just rm the testcases instead.

Patch

diff -r 3d2201b14581 gcc/doc/sourcebuild.texi
--- a/gcc/doc/sourcebuild.texi	Sat Aug 28 17:34:18 2010 +0200
+++ b/gcc/doc/sourcebuild.texi	Mon Aug 30 09:41:55 2010 +0200
@@ -1680,6 +1680,11 @@ 
 @item pthread_h
 Target has @code{pthread.h}.
 
+@item run_cpuhogs
+Testcases that consume excessive amounts of CPU time should be run on
+this target.  This can be enabled by setting the @env{RUN_CPUHOGS}
+environment variable to some non-empty string.
+
 @item simulator
 Test system runs executables on a simulator (i.e. slowly) rather than
 hardware (i.e. fast).
diff -r 3d2201b14581 gcc/testsuite/gcc.c-torture/compile/limits-fnargs.c
--- a/gcc/testsuite/gcc.c-torture/compile/limits-fnargs.c	Sat Aug 28 17:34:18 2010 +0200
+++ b/gcc/testsuite/gcc.c-torture/compile/limits-fnargs.c	Mon Aug 30 09:41:55 2010 +0200
@@ -1,4 +1,5 @@ 
 /* { dg-timeout-factor 4.0 } */
+/* { dg-require-effective-target run_cpuhogs } */
 
 #define PAR1 int, int, int, int, int, int, int, int, int, int
 #define PAR2 PAR1, PAR1, PAR1, PAR1, PAR1, PAR1, PAR1, PAR1, PAR1, PAR1
diff -r 3d2201b14581 gcc/testsuite/lib/target-supports.exp
--- a/gcc/testsuite/lib/target-supports.exp	Sat Aug 28 17:34:18 2010 +0200
+++ b/gcc/testsuite/lib/target-supports.exp	Mon Aug 30 09:41:55 2010 +0200
@@ -3579,3 +3579,13 @@ 
     }
  return 0
 }
+
+# Return 1 if CPU hogs (testcases that take excessive amounts of CPU time)
+# should be run.
+
+proc check_effective_target_run_cpuhogs { } {
+    if { [getenv RUN_CPUHOGS] != "" } {
+        return 1
+    }
+    return 0
+}