GCC Merge Process

We merge from the FSF release branch on the 1st Monday of each month. This page covers the process. Please note that it is different for different branches due to the repositories we store them in.

Generic process

The following Google Doc shows the pending backports which Linaro is considering for each branch:

https://docs.google.com/spreadsheet/ccc?key=0AtV9RnMAyyYXdFdnSi1QZUk2eXpLYnk3VFVPeldOSGc&usp=sharing

If you are doing merges it is your responsibility to keep the spreadhseet up to date.

In the week before the merge scan the previous month's bug fixes in GCC and see if any should be backported to the appropriate FSF branch, and encourage the process along upstream. Record these in the spreadsheet. We want any bug fix which will improve stability on x86, x86_64, ARM, or AArch64.

Also scan the changes for those feature changes that should be considered for backporting to the current development branch and record these in the spreadsheet. We will take any change that improves the ARM or AArch64 backend whoever has produced the fix.

GCC 4.7 Merge Process

For 4.7 we have two code sources from Subversion: branches/gcc-4_7-branch and branches/ARM/aarch64-4.7-branch. These are merged in two steps.

  1. Follow the instructions in Bazaar Tips to merge the FSF 4.7 branch with lp:gcc-linaro/4.7.

    1. This are the instructions for a broken Bzr repository.
    2. GCC is just too big for Bazaar to handle :-).
  2. For the AArch64 merge:
    1. bzr branch lp:~linaro-toolchain-dev/cbuild/tools cbuild-tools
    2. Edit cbuild-tools/aarch64-merger.sh - change the variables tip, from, current to reflect current status.
    3. bash cbuild-tools/aarch64-merger.sh
    4. File the merge request.

GCC 4.8 Merge Process

There are two parts to this process - the release branch merge, and feature backports merge. It is important in both of these that you use the svn merge functionality to make sure SVN can track the merges. This needs a relatviely modern version of SVN.

The release branch merge and feature backport merges can happen in any order provided you have a recent version of SVN (1.7 or later - maybe 1.5 or 1.6 but untested). Basically your Subversion version must understand and handle the svn:mergeinfo property.

FSF Release Branch merge

  1. Do any backports from trunk to the 4.8 branch (i.e. commits that fix regressions in 4.8).
  2. id=Your GCC Login ID
  3. svn checkout svn+ssh://$id@gcc.gnu.org/svn/gcc/branches/linaro/gcc-4_8-branch linaro-gcc-4_8-branch

  4. svn checkout svn+ssh://$id@gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch gcc-4_8-branch

  5. rev=Revision of the 'Daily bump' change for the first Monday in the month.
  6. cd linaro-gcc-4_8-branch
  7. svn merge ../gcc-4_8-branch@$rev
  8. cd ..
  9. bzr branch lp:gcc-linaro/4.8 4.8-YYYY.MM-branch-merge
  10. diff -ruNp -x '*.svn' -x '*~' -x '*.bzr' -x '*.rej' -x '*.orig' -x '*.edited' -x '*.git' 4.8-YYYY.MM-branch-merge linaro-gcc-4_8-branch > 4.8-YYYY.MM-branch-merge.txt

  11. cd 4.8-YYYY.MM-branch-merge
  12. bzr patch -p1 ../4.8-YYYY.MM-branch-merge.txt
  13. Add any new files, copy any binary files that weren't handled by diff.
  14. bzr commit -m"Merge branches/gcc-4_8-branch rev $rev"
  15. bzr push lp:~$(bzr lp-login)/gcc-linaro/4.8-YYYY.MM-branch-merge
  16. Generate merge request
  17. Once approved commit the SVN change.
  18. Once SVN commit has been made email gcc-patches@gcc.gnu.org with a notification of the merge.

Feature Backport merge

Feature backports should be merged individually so that each SVN commit reflects one feature addition. Note that features which are multiple commits may be backported as a single commit.

For each feature backport do the following:

  1. id=Your GCC Login ID
  2. svn checkout svn+ssh://$id@gcc.gnu.org/svn/branches/linaro/gcc-4_8-branch linaro-gcc-4_8-branch

  3. svn checkout svn+ssh://$id@gcc.gnu.org/svn/trunk trunk

  4. cd linaro-gcc-4_8-branch
  5. svn merge CHANGE_OPTIONS ../trunk
    • CHANGE_OPTIONS is -c REVNO to merge just REVNO
    • CHANGE_OPTIONS is -r N-1:M to merge changes from N to M, so -r 10:11 is equivalent to -c 11
    • CHANGE_OPTIONS can be a mix of -c and -r options, and they are applied left to right as specified on the command line.
  6. Handle any conflicts
  7. cd ..
  8. bzr branch lp:gcc-linaro/4.8 feature-merge-foo
  9. diff -ruNp -x '*.svn' -x '*~' -x '*.bzr' -x '*.rej' -x '*.orig' -x '*.edited' -x '*.git' feature-merge-foo linaro-gcc-4_8-branch > feature-merge-foo.txt

  10. cd feature-merge-foo
  11. bzr patch -p1 ../feature-merge-foo.txt
  12. Add any new files, copy any binary files that weren't handled by diff.
  13. bzr commit -m"Backport from trunk rREVISIONS"
  14. bzr push lp:~$(bzr lp-login)/gcc-linaro/feature-merge-foo
  15. Generate merge request
  16. Once approved commit the SVN change.
  17. Update spreadsheet with revisions merged
  18. Once SVN commit has been made email gcc-patches@gcc.gnu.org with a notification of the backport.

    • You can do a roll-up email if you are doing lots of backports.

To the propose a merge, go to https://code.launchpad.net/gcc-linaro, and click on the merge request. On the web page that takes you too, click on "propose merge. In the description field, enter in "Merge of ######" with ##### being the backport revision number.

You can see a list of all active merge requests at this page.

WorkingGroups/ToolChain/GCC/MergeProcess (last modified 2014-10-30 15:17:33)