blob: 844f676d80550a64b4253ae4c97cbbdc251f9f61 [file] [log] [blame]
Ian Lance Taylor2528f332009-11-06 14:15:41 -08001<!-- Contributing to the gccgo frontend -->
2
3<h2>Introduction</h2>
4
5<p>
6These are some notes on contributing to the <code>gccgo</code>
7frontend for GCC. For information on contributing to parts of Go other
8than <code>gccgo</code>, see <a href="contribute.html">Contributing to
9the Go project</a>. For information on building <code>gccgo</code>
Ian Lance Taylor5b387fb2009-11-06 14:36:34 -080010for yourself, see <a href="gccgo_install.html">Setting up and using
Ian Lance Taylor2528f332009-11-06 14:15:41 -080011gccgo</a>.
12</p>
13
14<h2>Legal Prerequisites</h2>
15
16<p>
Ian Lance Taylor9bebe742009-11-07 23:42:58 -080017You must follow the <a href="contribute.html#copyright">Go copyright
18rules.</a>
Ian Lance Taylor2528f332009-11-06 14:15:41 -080019</p>
20
21<h2>Code</h2>
22
23<p>
24The source code for the <code>gccgo</code> frontend may be found in
25the directory <code>gcc/go</code>. The frontend is written in C++ and
26as such the GNU coding standards do not entirely apply; in writing
27code for the frontend, follow the formatting of the surrounding code.
28Although the frontend is currently closely tied to the rest of the gcc
29codebase, we plan to make it more independent. Any new code which
30uses other parts of gcc should be segregated in an appropriate file,
31such as <code>gogo-tree.cc</code>.
32</p>
33
34<p>
35The runtime library for <code>gccgo</code> is mostly the same as the
36library in the main Mercurial repository. The library code in the
37Mercurial repository is periodically copied into
38the <code>gccgo</code> repository. Accordingly, most library changes
39should be made in Mercurial. Changes to the few <code>gccgo</code>
40specific parts of the library should follow the process described
41here. The <code>gccgo</code> specific parts of the library are
42everything in the <code>libgo</code> directory except for
43the <code>libgo/go</code> subdirectory.
44</p>
45
46<h2>Testing</h2>
47
48<p>
49All patches must be tested. There are two test suites. A patch that
50introduces new failures is not acceptable.
51</p>
52
53<p>
54To run the compiler test suite, run <code>make check-go</code> in the
55<code>gcc</code> subdirectory of your build directory. This will run
56various tests underneath <code>gcc/testsuite/go.*</code>. This
57includes a copy of the tests in the Mercurial repository, which are
58run using the DejaGNU script found in
59in <code>gcc/testsuite/go.test/go-test.exp</code>. Many of the
60compiler tests may be run without the Go library, but some do require
61the library to built first.
62</p>
63
64<p>
65To run the library test suite, run <code>make
66check-target-libgo</code> in the top level of your build directory.
67</p>
68
69<p>
70Most new tests should be submitted to the Mercurial repository for
71copying into the <code>gccgo</code> repository. If there is a need
72for specific tests for <code>gccgo</code>, they should go in
73the <code>gcc/testsuite/go.go-torture</code>
74or <code>gcc/testsuite/go.dg</code> directories.
75</p>
76
77<h2>Submitting Changes</h2>
78
79<p>
80Proposing a patch should follow the standard GCC rules. That is, the
81patch should be sent to the mailing
82list <code>gcc-patches@gcc.gnu.org</code> as a diff&mdash;the output
83of the <code>diff</code> program with the <code>-c</code>
84or <code>-u</code> option. In the future we are likely to set up a
85separate gccgo-specific mailing list, which should also be CC'ed; we
86will update this document at that time. Patch emails should include a
87ChangeLog entry, though the ChangeLog entry should not be in the diff
88itself. ChangeLog files are a standard part of GNU programs; see
89<a href="http://www.gnu.org/prep/standards/html_node/Change-Logs.html">the
90GNU coding standards</a>.
91</p>