initial commit

1 files changed, 87 insertions, 0 deletions

diff --git a/gcc/testsuite/README.gcc b/gcc/testsuite/README.gcc
new file mode 100755
index 0000000..17904bc
--- /dev/null
+++ b/gcc/testsuite/README.gcc
@@ -0,0 +1,87 @@
+This file contains a list of notes for those writing testcases and those
+writing expect scripts.  At present, they're in random order.
+
+Verbosity Levels
+
+- each level adds verbosity so level 2 prints all level 1 and level 2 stuff.
+
+1) Print a one-liner indicating the testcase being run (and maybe special
+   compiler options).
+
+2) Print compiler and program invocation including arguments and their output.
+   Proc's gcc_load and gcc_start handle the latter two.
+
+3) Print detailed testcase analysis like "Looking for pattern ...", etc.
+
+4) Maximum verbosity.  Print anything else of interest.
+
+send_log conventions
+
+Various messages are stored in gcc.log by the testing framework and we
+try to augment them with some of our own.  The format of the framework
+messages are:
+
+PASS: blah blah ...
+FAIL: blah blah ...
+
+so we use
+
+XXXX: blah blah ...
+
+Current messages are:
+
+EXEC: program being executed (so compiler path and args are recorded)
+STAT: intermediate pass/fail statistics
+
+Test scripts must ignore the compiler messages "path prefix never used"
+and "linker input file unused".  Don't let their appearance cause a testcase
+to fail.  See lib/dg.exp for the exact regsub to use.
+
+If you're unclear about which directory a testcase should be installed in,
+ask gcc-local.
+
+Have the text of a fail message be the same as that for pass.
+IE: have
+
+        if ...success...
+                pass "pr 1234"
+        else
+                fail "pr 1234"
+
+not
+
+        if ...success...
+                pass "pr 1234 passed"
+        else
+                fail "pr 1234 failed"
+
+
+This lets test-tool (which drives the nightly tests) do a better job
+at tracking which tests have digressed or been fixed.
+
+DO NOT PUT NON-PORTABLE TESTCASES IN gcc.c-torture.
+
+ANY TARGET SPECIFIC TESTCASE MUST HAVE APPROPRIATE CODE TO PREVENT IT FROM
+CAUSING A `FAILURE' ON UNSUPPORTED PLATFORMS.
+
+The "torture" tests are meant to be generic tests that can run on any
+target.  So you have to be careful about endianness, assumptions about
+sizes of datatypes, etc etc.
+
+For tests that merely need to compile, put them in the "compile" directory.
+
+For tests which should give an error, put them in the "noncompile" directory
+and update noncompile.exp appropriately (see examples in noncompile.exp).
+
+For IEEE FP specific tests, put them in execute/ieee.
+
+For execution tests, put them in execute.
+
+Always use abort() for runtime failures, and exit(0) for success.
+The testing harness is set up to watch for these and do something appropriate
+(when necessary) for target boards.
+
+If a test does not fit into the torture framework, use the dg framework.
+
+
+