Add a document on contributing to gccgo.

R=r, rsc
CC=go-dev
http://go/go-review/1025005

doc/contribute.html

@@ -11,7 +11,9 @@
 This document explains how to write a new package,
 how to test code, and how to contribute changes to the Go project.
 It assumes you have installed Go and Mercurial using the
-<a href="install.html">installation instructions</a>.
+<a href="install.html">installation instructions</a>.  (Note that
+the <code>gccgo</code> frontend lives elsewhere;
+see <a href="gccgo_contribute.html">Contributing to gccgo</a>.)
 </p>
 
 <p>

doc/gccgo_contribute.html

+<!-- Contributing to the gccgo frontend -->
+
+<h2>Introduction</h2>
+
+<p>
+These are some notes on contributing to the <code>gccgo</code>
+frontend for GCC.  For information on contributing to parts of Go other
+than <code>gccgo</code>, see <a href="contribute.html">Contributing to
+the Go project</a>.  For information on building <code>gccgo</code>
+for yourself, see <a href="go_gccgo_setup.html">Setting up and using
+gccgo</a>.
+</p>
+
+<h2>Legal Prerequisites</h2>
+
+<p>
+The <code>gccgo</code> frontend is part of the GCC compiler, and it
+follows the <a href="http://gcc.gnu.org/contribute.html">GCC
+contribution rules</a>.  In particular, for substantial
+patches&mdash;more than 10 lines&mdash;you must have a copyright
+assignment with the Free Software Foundation.
+</p>
+
+<h2>Code</h2>
+
+<p>
+The source code for the <code>gccgo</code> frontend may be found in
+the directory <code>gcc/go</code>.  The frontend is written in C++ and
+as such the GNU coding standards do not entirely apply; in writing
+code for the frontend, follow the formatting of the surrounding code.
+Although the frontend is currently closely tied to the rest of the gcc
+codebase, we plan to make it more independent.  Any new code which
+uses other parts of gcc should be segregated in an appropriate file,
+such as <code>gogo-tree.cc</code>.
+</p>
+
+<p>
+The runtime library for <code>gccgo</code> is mostly the same as the
+library in the main Mercurial repository.  The library code in the
+Mercurial repository is periodically copied into
+the <code>gccgo</code> repository.  Accordingly, most library changes
+should be made in Mercurial.  Changes to the few <code>gccgo</code>
+specific parts of the library should follow the process described
+here.  The <code>gccgo</code> specific parts of the library are
+everything in the <code>libgo</code> directory except for
+the <code>libgo/go</code> subdirectory.
+</p>
+
+<h2>Testing</h2>
+
+<p>
+All patches must be tested.  There are two test suites.  A patch that
+introduces new failures is not acceptable.
+</p>
+
+<p>
+To run the compiler test suite, run <code>make check-go</code> in the
+<code>gcc</code> subdirectory of your build directory.  This will run
+various tests underneath <code>gcc/testsuite/go.*</code>.  This
+includes a copy of the tests in the Mercurial repository, which are
+run using the DejaGNU script found in
+in <code>gcc/testsuite/go.test/go-test.exp</code>.  Many of the
+compiler tests may be run without the Go library, but some do require
+the library to built first.
+</p>
+
+<p>
+To run the library test suite, run <code>make
+check-target-libgo</code> in the top level of your build directory.
+</p>
+
+<p>
+Most new tests should be submitted to the Mercurial repository for
+copying into the <code>gccgo</code> repository.  If there is a need
+for specific tests for <code>gccgo</code>, they should go in
+the <code>gcc/testsuite/go.go-torture</code>
+or <code>gcc/testsuite/go.dg</code> directories.
+</p>
+
+<h2>Submitting Changes</h2>
+
+<p>
+Proposing a patch should follow the standard GCC rules.  That is, the
+patch should be sent to the mailing
+list <code>gcc-patches@gcc.gnu.org</code> as a diff&mdash;the output
+of the <code>diff</code> program with the <code>-c</code>
+or <code>-u</code> option.  In the future we are likely to set up a
+separate gccgo-specific mailing list, which should also be CC'ed; we
+will update this document at that time.  Patch emails should include a
+ChangeLog entry, though the ChangeLog entry should not be in the diff
+itself.  ChangeLog files are a standard part of GNU programs; see
+<a href="http://www.gnu.org/prep/standards/html_node/Change-Logs.html">the
+GNU coding standards</a>.
+</p>