PATCH: gcc-3.1/criteria.html

[Gerald Pfeifer]

This update to the GCC 3.1 release criteria was approved by Mark in
private mail.

It makes some sentences a bit more generic and notes application criteria
as optional (though desirable).

Installed.

Gerald


Index: criteria.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.1/criteria.html,v
retrieving revision 1.18
diff -u -3 -p -r1.18 criteria.html
--- criteria.html	3 Apr 2002 22:34:50 -0000	1.18
+++ criteria.html	10 Apr 2002 12:47:46 -0000
@@ -162,10 +162,16 @@ test with <code>-fPIC</code> as well.</p
 <code>--enable-checking</code> failures when running any of the
 regression test-suites.</p>

-<h2>Applications</h2>
+<h2>Additional Tests</h2>

-<p>In addition to the regression-testing mentioned above, it is
-important that operation of the compiler be verified on some real-world
+<p>Ideally, strict compliance with the following criteria would be
+required for all releases of GCC, however this is simply not practical
+for GCC 3.1.  Still, testers are encouraged to perform these tests and
+report possible problems.</p>
+
+<h3>Applications</h3>
+
+<p>It is important that the compiler is verified on real-world
 applications.  The following applications represent a mix of low-level
 and high-level code, of numerical and logical programs, and of
 different programming languages.</p>
@@ -247,8 +253,8 @@ different programming languages.</p>

 <p>These selections were made for a variety of reasons.  The Linux kernel is
 one of the most important pieces of free software, and kernel developers pay
-careful attention to GCC performance.  It would be an embarrassment to GCC
-3.1 if it did not compile the kernel correctly, out of the box.  The kernel
+careful attention to GCC performance.  It would be an embarrassment if GCC
+did not compile the kernel correctly, out of the box.  The kernel
 taxes many of the low-level aspects of GCC, as well as many GCC extensions,
 including the extended assembly syntax, addresses of labels, and so forth.
 (Historically, there have been kernel bugs, found only by more aggressive
@@ -264,22 +270,15 @@ In addition, templates have historically
 memory at compile-time.  With the widespread prevalence of templates in
 C++ programs, including the standard library, testing this area heavily is
 vitally important.  For instructions on how to set up and build POOMA and
-check the outcome of its testing programs see <a href="pooma-guide.html">
+check the outcome of its testing programs see <a href="testing-pooma.html">
 this guide</a>.</p>

 <p>LAPACK is a well known linear algebra package that contains code
 typical for large scale Fortran programs.  For instructions on how to set
 up and build LAPACK and check the outcome of its testing programs see <a
-href="lapack-guide.html"> this guide</a>.</p>
+href="testing-lapack.html">this guide</a>.</p>

-<p>As progress is made towards the release, specific information about how
-these programs should be compiled, and how their correct operation should
-be verified will be made available here.  In general, however, the purpose
-will not be to exhaustively test these applications; instead, testers
-should simply verify that they compile, and perform basic functionality
-correctly.</p>
-
-<h2>Code Quality</h2>
+<h3>Code Quality</h3>

 <p>Historically, there has been no formal release criterion that took into
 account performance of code generated by the compiler.  It is important that
@@ -314,14 +313,13 @@ behavior of the elliptic curve integer f
 href="ftp://ftp.loria.fr/pub/loria/eureca/tmp/GMP-ECM/ecm4c.c">ecm4c.c</a>,
 which uses GNU mp, will be considered part of the release criteria.</p>

-<p>A release candidate will be deemed unacceptable if the performance of
-the generated code is not at least as good as that of past releases of GCC
-since 2.95.3 on the benchmarks, and within at least 5% on the application
-tests.</p>
+<p>The performance of the generated code of a release candidate should be
+at least as good as that of past releases of GCC since 2.95.3 on the
+benchmarks, and within at least 5% on the application tests.</p>

-<h2>Compile-Time Performance</h2>
+<h3>Compile-Time Performance</h3>

-<p>There is a perception that development snapshots take longer to compile
+<p>There is a perception that current versions of GCC take longer to compile
 programs than their 2.95.3 counterparts, and that they often use more memory
 as well.  Compile-time performance is an important part of compiler quality.
 It is not enough simply to provide additional optimizations; the compiler
@@ -354,13 +352,12 @@ following unit tests:</p>
 </tr>
 </table>

-<p>In addition to these unit tests, we will measure the time and peak
-memory usage used when building the entire GNU Emacs distribution with
-both GCC 2.95.3 and GCC 3.1.</p>
-
-<p>If the release candidate's compile-time exceeds GCC 2.95.3 by more than
-15%, or if the peak memory usage exceeds that of GCC 2.95.3 by more than
-25%, that candidate will be deemed unacceptable.</p>
+<p>In addition to these unit tests, time and peak memory usage used
+when building the entire GNU Emacs distribution should be measured.</p>
+
+<p>A release candidate's compile-time should not exceed GCC 2.95.3 by
+more than 15%, and peak memory usage should not exceed that of GCC 2.95.3
+by more than 25%.</p>

 </body>
 </html>