Submitting a Patch

Submitting a patch will look like this:

1) Making sure you have filed a copyright assignment form (the maintainers will ask you whether you have done this when you submit your patch).

2) Cloning the source from git (don't try and be clever and download a non-git [i.e. .zip] version of GCC. You WILL need git to generate the patch). You will want to clone it twice - once for a clean build and another time for the build you make changes to. This is so you can compare regression test results.

3) Making your changes.

4) Fully compiling (bootstrapping) the compiler to make sure it works.

5) Performing regression testing on the build. Adding new regression tests if appropriate.

6) Generating the patch.

The first five steps are documented elsewhere on this wiki.

Generating The Patch
1) Perform steps 1-5 above.

2) Run contrib/gcc-git-customization.sh (you may not need to do this if you've done this before, but it probably doesn't hurt to do it again).

3) Do git add * to add your changes.

4) Do git gcc-commit-mklog and enter the commit message (you can always edit this later with git commit --amend ). The commit message should be the subject of the patch (e.g. "c++: private inheritance access diagnostics fix [PR17314]"), followed by a blank line, and then an explanation/rationale. As an example, the start should look something like this:



5) Run git gcc-verify, making sure there are no issues.

6) Do git format-patch -1 HEAD . This will generate a patch file.

7) Check your patch has no formatting issues by running contrib/check_GNU_style.sh on your new patch file.

8) Submit!

Formatting The Code
The code must meet certain style requirements:


 * Each line of a comment must be in-line with each other (i.e. the start of the actual text of the comment).
 * In an if statement, curly brackets { } are indented by two spaces after the if statement, etcetera.
 * There should be NO WHITESPACE at the end of any line.
 * If you have a place where there are 7 or more spaces, it should be replaced with tabs (with additional spaces after the tabs, if necessary).
 * If you overflow the arguments of a function onto a new line, it must be aligned with the first argument on the first line.
 * Dates IN THE COMMIT MESSAGE need to be formatted in the following way: yyyy-mm-dd. So, for the 7th January 2021, instead of 2021-1-7, do 2021-01-07 (remember that GCC uses Americanised dates).
 * After a curly bracket { }, indent by two spaces.
 * There should be spaces before round brackets . e.g. if (true).
 * You need TWO SPACES after each sentence in a comment (even at the end).

Communicating With Maintainers
This is scary at first, especially if you've never used a Linux mailing list before. Essentially, all you have to do is email the mailing list, and someone will get back to you. When someone replies you will also get the exact same email in your email inbox in your mail client. To reply, all you have to do is press "reply all" (this makes sure it also goes to the mailing list). You can attach files to your emails too and they will be included on the mailing list.

In your email it's nice to say what you have done, what tests you have done and why. You may want to include:


 * The results of any regression analyses (e.g. before vs after).
 * What build targets you used and what you built it on.