On Tue, 17 May 2005, Joel Sherrill <[EMAIL PROTECTED]> wrote: >> For future reference, where patches should be sent is explained here: >> http://gcc.gnu.org/lists.html > OK .. and Bugzilla or http://gcc.gnu.org/bugs.html references that link how?
I'm not sure we should add a link to lists.html from bugs.html, however when reviewing the current bugs.html page I noticed that it's way too baroque and committed the following patch. Any further simplifications and other patches are most welcome! Gerald Rephrase some parts to make them shorter. Omit some details for submitting bugs by e-mail. Index: bugs.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/bugs.html,v retrieving revision 1.93 diff -u -3 -p -r1.93 bugs.html --- bugs.html 23 Feb 2005 22:42:09 -0000 1.93 +++ bugs.html 17 May 2005 20:47:46 -0000 @@ -53,13 +53,13 @@ <h1><a name="report">Reporting Bugs</a></h1> <p>The main purpose of a bug report is to enable us to fix the bug. The -most important prerequisite for this is that the report must be complete and -self-contained, which we explain in detail below.</p> +most important prerequisite for this is that the report must be complete +and self-contained.</p> <p>Before you report a bug, please check the -<a href="#known">list of well-known bugs</a> and, <strong>if possible -in any way, try a current development snapshot</strong>. -If you want to report a bug with versions of GCC before 3.1 we strongly +<a href="#known">list of well-known bugs</a> and, <strong>if possible, +try a current development snapshot</strong>. +If you want to report a bug with versions of GCC before 3.4 we strongly recommend upgrading to the current release first.</p> <p>Before reporting that GCC compiles your code incorrectly, please @@ -116,10 +116,6 @@ three of which can be obtained from the a successful compilation; this is a symptom of a hardware problem, not of a compiler bug (sorry)</li> - <li>E-mail messages that complement previous, incomplete bug - reports. Post a new, self-contained, full bug report instead, if - possible as a follow-up to the original bug report</li> - <li>Assembly files (<code>*.s</code>) produced by the compiler, or any binary files, such as object files, executables, core files, or precompiled header files</li> @@ -163,17 +159,6 @@ preprocessed file it generates.</p> <blockquote><p><code>gcc -v -save-temps <i>all-your-options source-file</i></code></p></blockquote> -<p>Typically the preprocessed file (extension <code>.i</code> for C or -<code>.ii</code> for C++, and <code>.f</code> if the preprocessor is used on -Fortran files) will be large, so please compress the -resulting file with one of the popular compression programs such as -bzip2, gzip, zip or compress (in -decreasing order of preference). Use maximum compression -(<code>-9</code>) if available. Please include the compressed -preprocessor output in your bug report, even if the source code is -freely available elsewhere; it makes the job of our volunteer testers -much easier.</p> - <p>The <b>only</b> excuses to not send us the preprocessed sources are (i) if you've found a bug in the preprocessor, (ii) if you've reduced the testcase to a small file that doesn't include any other file or @@ -186,12 +171,6 @@ then try to create a small file that tri it in the bug report, although you may want to post parts of it to point out assembly code you consider to be wrong.</p> -<p>Whether to use MIME attachments or <code>uuencode</code> is up to -you. In any case, make sure the compiler command line, version and -error output are in plain text, so that we don't have to decode the -bug report in order to tell who should take care of it. A meaningful -subject indicating language and platform also helps.</p> - <p>Please avoid posting an archive (.tar, .shar or .zip); we generally need just a single file to reproduce the bug (the .i/.ii/.f preprocessed file), and, by storing it in an archive, you're just making our @@ -204,16 +183,6 @@ make sure the compiler version, error me the body of your bug report as plain text, even if needlessly duplicated as part of an archive.</p> -<p>If you fail to supply enough information for a bug report to be -reproduced, someone will probably ask you to post additional -information (or just ignore your bug report, if they're in a bad day, -so try to get it right on the first posting :-). In this case, please -post the additional information to the bug reporting mailing list, not -just to the person who requested it, unless explicitly told so. If -possible, please include in this follow-up all the information you had -supplied in the incomplete bug report (including the preprocessor -output), so that the new bug report is self-contained.</p> - <h2><a name="gnat">Detailed bug reporting instructions for GNAT</a></h2> <p>See the <a href="#detailed">previous section</a> for bug reporting
