diff --git a/doc/contribute.html b/doc/contribute.html
index 92190ca37c6..e2df8bb3d5b 100644
--- a/doc/contribute.html
+++ b/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
-installation instructions.
+installation instructions. (Note that
+the gccgo
frontend lives elsewhere;
+see Contributing to gccgo.)
diff --git a/doc/gccgo_contribute.html b/doc/gccgo_contribute.html new file mode 100644 index 00000000000..57a59587d01 --- /dev/null +++ b/doc/gccgo_contribute.html @@ -0,0 +1,94 @@ + + +
+These are some notes on contributing to the gccgo
+frontend for GCC. For information on contributing to parts of Go other
+than gccgo
, see Contributing to
+the Go project. For information on building gccgo
+for yourself, see Setting up and using
+gccgo.
+
+The gccgo
frontend is part of the GCC compiler, and it
+follows the GCC
+contribution rules. In particular, for substantial
+patches—more than 10 lines—you must have a copyright
+assignment with the Free Software Foundation.
+
+The source code for the gccgo
frontend may be found in
+the directory gcc/go
. 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 gogo-tree.cc
.
+
+The runtime library for gccgo
is mostly the same as the
+library in the main Mercurial repository. The library code in the
+Mercurial repository is periodically copied into
+the gccgo
repository. Accordingly, most library changes
+should be made in Mercurial. Changes to the few gccgo
+specific parts of the library should follow the process described
+here. The gccgo
specific parts of the library are
+everything in the libgo
directory except for
+the libgo/go
subdirectory.
+
+All patches must be tested. There are two test suites. A patch that +introduces new failures is not acceptable. +
+ +
+To run the compiler test suite, run make check-go
in the
+gcc
subdirectory of your build directory. This will run
+various tests underneath gcc/testsuite/go.*
. This
+includes a copy of the tests in the Mercurial repository, which are
+run using the DejaGNU script found in
+in gcc/testsuite/go.test/go-test.exp
. Many of the
+compiler tests may be run without the Go library, but some do require
+the library to built first.
+
+To run the library test suite, run make
+check-target-libgo
in the top level of your build directory.
+
+Most new tests should be submitted to the Mercurial repository for
+copying into the gccgo
repository. If there is a need
+for specific tests for gccgo
, they should go in
+the gcc/testsuite/go.go-torture
+or gcc/testsuite/go.dg
directories.
+
+Proposing a patch should follow the standard GCC rules. That is, the
+patch should be sent to the mailing
+list gcc-patches@gcc.gnu.org
as a diff—the output
+of the diff
program with the -c
+or -u
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
+the
+GNU coding standards.
+