This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: gcc/gcc/testsuite ChangeLog gcc.dg/20040203-1. ...
On Tue, 3 Feb 2004, Paolo Carlini wrote:
> Ok, thanks Michael and Joseph. Indeed, I can only agree with you: FWIW in
> libstdc++-v3 we use directories corresponding to each standard chapter and
> the PR number or a generic number if there isn't one. Definitely, we don't
> use dates ;)
>
> Unfortunately, a quick (well, not so quick ;) glance at the current gcc.dg
> testsuite is not revealing about the right policy...
>
> Could you possibly write it down for the benefit of newcomers?
How does the following patch documenting a convention for testcases for
PRs seem?
Note, I'd welcome people renaming testcases with date names that mention
the relevant PR in a comment. Some might object to this breaking
regression testing, but the best regression testing for new releases is to
run the *new* testsuite with *both* the new and old compilers and compare
the results, which used to be done as standard in advance of making new
releases.
Note that gcc.dg/torture exists to run gcc.dg-style testcases over
multiple optimisation options (in addition to any special options
specified in that testcase). This may be an appropriate destination for
many gcc.dg testcases that presently run with just one particular
optimisation option but could get better coverage by running with many
options. Of course tests purely for warnings that are nothing to do with
optimisation shouldn't go there.
--- sourcebuild.texi.orig 2004-01-25 17:41:32.000000000 +0000
+++ sourcebuild.texi 2004-02-03 17:18:45.000000000 +0000
@@ -788,13 +788,21 @@
@node Test Idioms
@subsection Idioms Used in Test Suite Code
-In the @file{gcc.c-torture} test suites, test cases are commonly named
-after the date on which they were added. This allows people to tell
-at a glance whether a test failure is because of a recently found bug
-that has not yet been fixed, or whether it may be a regression. In
-other test suites, more descriptive names are used. In general C test
-cases have a trailing @file{-@var{n}.c}, starting with @file{-1.c}, in
-case other test cases with similar names are added later.
+In general C testcases have a trailing @file{-@var{n}.c}, starting
+with @file{-1.c}, in case other testcases with similar names are added
+later. If the test is a test of some well-defined feature, it should
+have a name referring to that feature such as
+@file{@var{feature}-1.c}. If it does not test a well-defined feature
+but just happens to exercise a bug somewhere in the compiler, and a
+bug report has been filed for this bug in the GCC bug database,
+@file{pr@var{bug-number}-1.c} is the appropriate form of name.
+Otherwise (for miscellaneous bugs not filed in the GCC bug database),
+and previously more generally, test cases are named after the date on
+which they were added. This allows people to tell at a glance whether
+a test failure is because of a recently found bug that has not yet
+been fixed, or whether it may be a regression, but does not give any
+other information about the bug or where discussion of it may be
+found. Some other language testsuites follow similar conventions.
Test cases should use @code{abort ()} to indicate failure and
@code{exit (0)} for success; on some targets these may be redefined to
--
Joseph S. Myers
jsm@polyomino.org.uk