Applied. (gcc-bugs also has changed its usage, it's not meant for direct posting any more.)
Gerald Index: contribute.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v retrieving revision 1.84 diff -u -r1.84 contribute.html --- contribute.html 22 Jun 2014 13:07:07 -0000 1.84 +++ contribute.html 27 Jun 2014 11:07:43 -0000 @@ -68,10 +68,9 @@ <p>Submissions which do not conform to the standards will be returned with a request to address any such problems. To help with the -preparation of patches respecting these rules, one can use the script -<a href="https://gcc.gnu.org/viewcvs/gcc/trunk/contrib/check_GNU_style.sh";> -contrib/check_GNU_style.sh</a> to detect some of the common -mistakes. </p> +preparation of patches you can use the script <a href= +"https://gcc.gnu.org/viewcvs/gcc/trunk/contrib/check_GNU_style.sh?view=markup";> +contrib/check_GNU_style.sh</a>.</p> <!-- also referenced from svnwrite.html --> <h2><a name="testing">Testing Patches</a></h2> @@ -79,8 +78,7 @@ <p>All patches must be thoroughly tested. We encourage you to test changes with as many host and target combinations as is practical. In addition to using real hardware, you can -<a href="simtest-howto.html">use simulators</a> to increase your test -coverage.</p> +<a href="simtest-howto.html">use simulators</a>.</p> <p>Much of GCC's code is used only by some targets, or used in quite different ways by different targets. When choosing targets to test a @@ -91,7 +89,7 @@ <p>You will of course have tested that your change does what you expected it to do: fix a bug, improve an optimization, add a new -feature. If the test framework permits, you should automate these +feature. Where possible you should automate these tests and add them to GCC's testsuite. You must also perform regression tests to ensure that your patch does not break anything else. Typically, this means comparing post-patch test results to @@ -104,9 +102,8 @@ <p>If your change is to code that is not in a front end, or is to the C front end, you must perform a complete build of GCC and the runtime libraries included with it, on at least one target. You must -bootstrap all default languages, not just C. You must also run all of the -testsuites included with GCC and its runtime libraries. For a normal -native configuration, running</p> +bootstrap all default languages, not just C, and run all testsuites. +For a normal native configuration, running</p> <blockquote><pre> make bootstrap make -k check @@ -141,9 +138,7 @@ <p>In all cases you must test exactly the change that you intend to submit; it's not good enough to test an earlier variant. The tree where you perform this test should not have any other changes applied -to it, because otherwise you cannot be sure that your patch will work -correctly on its own. Include all your new testcases in your -testsuite run.</p> +to it. Include all your new testcases in your testsuite run.</p> <h2><a name="docchanges">Documentation Changes</a></h2> @@ -192,8 +187,7 @@ For new features a description of the feature and your implementation. For bugs a description of what was wrong with the existing code, and a reference to any previous bug report (in the -<a href="https://gcc.gnu.org/bugzilla/";>GCC bug tracker</a> or the -<a href="http://gcc.gnu.org/ml/gcc-bugs/";>gcc-bugs archives</a>) and any +<a href="https://gcc.gnu.org/bugzilla/";>GCC bug tracker</a>) and any existing testcases for the problem in the GCC testsuite. </dd>
