@@ -1,5 +1,6 @@
<!DOCTYPE html>
<html lang="en">
+
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Contributing to the GCC project." />
@@ -12,12 +13,11 @@
<body>
<h1>Contributing to GCC</h1>
-<p>We strongly encourage individuals as well as organizations to
-contribute to the development of GCC in the form of new features, new
+<p>We strongly encourage contributions in the form of features, new
or improved optimizations, bug fixes, documentation updates, web page
improvements, etc....</p>
-<p>There are certain legal requirements and style issues which all
+<p>There are certain legal requirements and style issues which
contributions must meet:</p>
<ul>
@@ -52,11 +52,10 @@ your request.</p>
<p>If a contributor is reluctant to sign a copyright assignment for a
change, a copyright disclaimer to put the change in the public domain is
-acceptable as well. The copyright disclaimer form is different than an
-employer disclaimer form. A copyright assignment is more convenient if a
+acceptable as well. A copyright assignment is more convenient if a
contributor plans to make several separate contributions.</p>
-<p>Small changes can be accepted without a copyright disclaimer or a
+<p>We can accept small changes without a copyright disclaimer or a
copyright assignment on file.</p>
@@ -85,9 +84,7 @@ addition to using real hardware, you can
<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
patch with, make sure that your selections exercise all aspects of the
-code you are changing. For instance, a change to conditional branch
-handling should be tested both with targets that use <code>cc0</code>,
-and targets that don't.</p>
+code you are changing.</p>
<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
@@ -127,9 +124,8 @@ must perform a complete bootstrap; however, running other language
testsuites is not necessary.</p>
<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. Include all your new testcases in your testsuite run.</p>
+submit. The tree where you perform this test should not have any
+other changes applied.</p>
<h2 id="docchanges">Documentation Changes</h2>
@@ -207,14 +203,8 @@ of your testing.
<dt>The patch itself</dt>
<dd>
-If you are accessing the <a href="svn.html">SVN repository</a> at
-gcc.gnu.org, please configure your svn to use GNU diff
-and generate patches using the "<code>-up</code>" or
-"<code>-cp</code>" options.
-See <a href="https://gcc.gnu.org/wiki/SvnSetup">SVN setup instructions</a>
-for more details.<br />
Do not include generated files as part of the patch, just mention
-them in the ChangeLog (e.g., "* configure: Regenerate.").
+them in the ChangeLog (e.g., "<code>* configure: Regenerate.</code>").
</dd>
</dl>
@@ -234,14 +224,11 @@ the changes that actually make use of the new code and change GCC's
behavior.)</p>
<p>We prefer patches posted as plain text or as MIME parts of type
-<code>text/x-patch</code> or <code>text/plain</code>, disposition
-<code>inline</code>, encoded as <code>7bit</code> or
-<code>8bit</code>.
+<code>text/x-patch</code> or <code>text/plain</code>.
It is strongly discouraged to post patches as MIME parts of type
<code>application/</code><i>whatever</i>, disposition
<code>attachment</code> or encoded as <code>base64</code> or
-<code>quoted-printable</code>. Avoid MIME large-message splitting
-(<code>message/partial</code>) at all costs.</p>
+<code>quoted-printable</code>.</p>
<p> If the patch is too big or too mechanical, posting it gzipped or
bzip2ed and uuencoded or encoded as a <code>base64</code> MIME part is