What is the developer policy of bumping the version of submodules?

[lazyparser]

I observed that the submodules were got updated/bumped in different time, from 2 months ago to 9 months ago.

Do we have a developer policy or guide for bumping riscv-gcc, riscv-binutils, and riscv-newlib?

[jim-wilson]

There is no formal policy. It depends on the branch, and the bug report. If it is an important branch and bug report, then the bump will generally happen immediately. If it not an important branch or bug report, then the bump may be delayed so that we don't have the do lots of bumps. The main issue is lack of time and personnel to do the work. Note that if you bump something in riscv-gnu-toolchain, then you actually need to test that you haven't broken it. The best test is to cd into the regression dir and run make which builds and checks a number of configurations (26?). That can take a day.

[lazyparser]

There is no formal policy. It depends on the branch, and the bug report. If it is an important branch and bug report, then the bump will generally happen immediately. If it not an important branch or bug report, then the bump may be delayed so that we don't have the do lots of bumps. The main issue is lack of time and personnel to do the work. Note that if you bump something in riscv-gnu-toolchain, then you actually need to test that you haven't broken it. The best test is to cd into the regression dir and run make which builds and checks a number of configurations (26?). That can take a day.

Oh thanks for the regression testing method, that is exactly what I was searching for. I'll add it to CI :-)

I am building CI/CD for riscv-gnu-toolchain and faced a few failures like #852 . Not sure what is the root cause though, but if there were bugs in submodules and got fixed in upstream, bumping submodules would help/fix.

I'd like to submit some PRs bumping submodules after all the regresstion tests passed.

[kito-cheng]

It's my logic for dump toolchain version, basically are very similar what Jim described:

• Bump when a stable release version out.
  • e.g. GCC 10.2 is released, binutils 2.36 is released...
• Bug fix, mostly for GCC
  • Cherry-pick the bug fix to the stable version on github tree.
• Feature or optimization back-port, mostly for GCC
  • Cherry-pick the new features to the stable version on github tree, it will not happen on upstream release branch, since the policy is only back-port bug fix.

[jim-wilson]

This is more of a problem for branches than master. On the rvv-intrinsic branch for instance, riscv-gcc is about 6 commits ahead of riscv-gnu-toolchain. There are also cross repo dependencies. For the B extension, the binutils/gcc branches are ahead of riscv-binutils, and we don't have any control over riscv-bitmanip.

[lazyparser]

Hi @jim-wilson @kito-cheng

Now we can enable more branches/commits combinations for CI (build and regression testing).

Feel free to list the build configs here, and I will added them as new CI jobs in ci.rvperf.org:

build config

• OS type. currently we have [ubuntu2004, ubuntu1804]. It is easy to add more OS if needed.
• Toolchain config. I use the default GNU Toolchain provided by OS Distro by default.
• branch name or commit of riscv-gnu-toolchain
• submodule steps. for each submodule
  • should I run git checkout branch/commit/pull in submodule or just keep it as default commit.
• Tests need to run. Default: cd regression && make report-gcc && make report-binutils

For example:

try bump them all

• ubuntu1804
• (no need to list toolchain if we use the default one)
• master
• bump gcc, bump binutils, bump gdb, do not bump qemu.
• all regression tests

rvv-intrinsics

• ubuntu1804 and ubuntu2004
• meta repo branch: https://github.com/riscv/riscv-gnu-toolchain/tree/rvv-intrinsic
• submodule: as is
• all regress

ref: #852 (comment)

Currently the RVPrefCI has 2 ubuntu2004 and 3 ubuntu1804, so we can have more than dozens configs running on a daily basis.

[jim-wilson]

There aren't any interesting branches other than master in riscv-gnu-toolchain. There are no actively maintained development branches, and we are in the process of moving development to upstream (i.e. FSF) git trees. The master branch should have up to date submodules. If not, I'd consider that a bug. It is the development branches that aren't always up to date with respect to submodules.

Using riscv-gnu-toolchain to test upstream mainline branches would be interesting.

Note that a build in the regression dir isn't going to be useful for development work, as none of the targets being built including any extensions under development.

[lazyparser]

@jim-wilson @kito-cheng Thanks for the clarification. That's very clear to me now.

So the next things I'd like to try are:

• keep testing master branch
• use a new branch for daily bumping of gcc, binutils, glibc, newlib, gdb, (and dejagnu?). https://github.com/plctlab/riscv-gnu-toolchain/tree/fsf-daily-bump
• If CI against fsf-daily-bump passes, bump fsf-cutting-edge as a stable test version for further testing. https://github.com/plctlab/riscv-gnu-toolchain/tree/fsf-cutting-edge
• Filing bugs directly to upstream's bugzilla.

[jim-wilson]

riscv-gnu-toolchain currently uses FSF releases, with some patches backported. Daily bumping doesn't make sense for that, as FSF releases don't happen every day. They happen maybe twice a year, at different times for different packiages. If you want to add tracking branches, e.g. a branch to track the FSF release branches, or a branch to track FSF upstream mainline, then daily bumps might make sense for that.

Maybe we are using the word "bump" differently. If riscv-gnu-toolchain is currently using gcc-10.1, and we want to move to gcc-10.2, then we call that a gcc bump. A daily bump makes no sense here, since there can only be a bump when there is a new gcc release.

And note that we really should be adding bug fix patches to the upstream FSF branches, not to riscv-gnu-toolchain. Linux distros won't get the fixes for instance if they are only in riscv-gnu-toolchain, so linux distros use the FSF release branches.

[lazyparser]

riscv-gnu-toolchain currently uses FSF releases, with some patches backported. Daily bumping doesn't make sense for that, as FSF releases don't happen every day. They happen maybe twice a year, at different times for different packiages. If you want to add tracking branches, e.g. a branch to track the FSF release branches, or a branch to track FSF upstream mainline, then daily bumps might make sense for that.

I was meaning the mainline branch (trunk) of upstream gcc. After that I can look into FSF release branches like gcc-10-branch.

Maybe we are using the word "bump" differently. If riscv-gnu-toolchain is currently using gcc-10.1, and we want to move to gcc-10.2, then we call that a gcc bump. A daily bump makes no sense here, since there can only be a bump when there is a new gcc release.

Ah, yes. By daily bump I mean pull the mainline branch everyday or every hour, and build it if new commits comes.

I'll try to avoid misuse the term bump.

And note that we really should be adding bug fix patches to the upstream FSF branches, not to riscv-gnu-toolchain. Linux distros won't get the fixes for instance if they are only in riscv-gnu-toolchain, so linux distros use the FSF release branches.

Sure. The plctlab/riscv-gnu-toolchain is only used for CI. It is more convenient for me (the CI) to track the commits by a meta repo instead of pull them in the build scripts. No patches will be applied on plctlab/riscv-gnu-toolchain