On Thu, Jan 11, 2024 at 3:45 AM Ken Matsui <kmat...@cs.washington.edu> wrote: > > On Thu, 11 Jan 2024 at 11:14, Jonathan Wakely <jwak...@redhat.com> wrote: > > On Thu, 11 Jan 2024 at 10:56, Ken Matsui <kmat...@gcc.gnu.org> wrote: > > > > > > On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely <jwak...@redhat.com> wrote: > > > > On Thu, 11 Jan 2024 at 09:43, Ken Matsui <kmat...@gcc.gnu.org> wrote: > > > > > > > > > > This patch made std::filesystem::equivalent correctly throw an > > > > > exception > > > > > when either path does not exist as per [fs.op.equivalent]/4. > > > > > > > > Thanks, OK for trunk and all active branches (let me know if you need > > > > help backporting it). > > > > > > > > > > Thank you for your review as always! I do not know how to backport this > > > to the active branches. I think the following page is explaining it, > > > but I am not sure how I can know all the active branches. > > > > > > https://gcc.gnu.org/wiki/GitCookbook#backport > > > > Supported releases are listed on the front page at gcc.gnu.org, the > > active branches are currently releases/gcc-11, releases/gcc-12 and > > releases/gcc-13. > > > > > > > > Do we basically want to git checkout & gcc-backport for each branch > > > after this patch is committed to the trunk? > > > > Almost. I use gcc-backport for the newest release branch > > (releases/gcc-13) and then I just use 'git cherry-pick' to cherry-pick > > the gcc-13 commit onto gcc-12, and then cherry-pick the gcc-12 commit > > onto gcc-11. > > > > The reason for this is that there might be some changes needed on a > > branch, either to resolve conflicts, or because of other differences > > on the branch. e.g. when I did 'git gcc-backport 74a0dab18292be' to > > backport that to gcc-13 I had to remove the changes to > > include/bits/version.* and edit include/std/version instead (because > > we do feature test macros differently on trunk). > > > > If I then wanted to backport it to gcc-12 and I just did 'git > > gcc-backport 74a0dab18292be' again in the gcc-12 branch, I would have > > to resolve the same conflicts again. If I do 'git cherry-pick > > c5ef02e5629f8c' instead (using the hash of the commit on the gcc-13 > > branch) then it will apply cleanly to gcc-12, because I'm using the > > commit that already has the conflicts resolved. > > > > Then if I want to backport to gcc-11 as well, use cherry-pick with the > > hash from the gcc-12 branch. > > > > This way any fixes that were needed for branch N-1 will get backported > > to N-2 as well. Sometimes this doesn't matter, e.g. the trunk commit > > might apply cleanly to every branch. But sometimes the commit needs > > slightly more massaging to apply to each older branch, so doing it > > trunk->13 then 13->12 then 12->11 tends to work better. > > > > The reason I use cherry-pick after the first backport (instead of > > gcc-backport every time) is because I don't want a second "(cherry > > picked from commit ...)" line to be added to the commit message. > > That's added by gcc-backport (by using cherry-pick -x) but we only > > need to add it once to be able to track the provenance of the > > backport, to know which trunk patch was backported. > > > > If cherry picking a backport fails and creates a mess of conflicts and > > you just want to give up and start again, 'git cherry-pick --abort' > > will undo the changes and leave the working tree clean again. This > > works whether you use gcc-backport or cherry-pick (because > > gcc-backport just uses cherry-pick). > > > > Thank you for the detailed explanation! I think I was able to backport > the patch to the active branches. >
For the Bugzilla issue, should I update the status to RESOLVED? Or does someone else handle this? Also, are there other things I should do about this issue? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250 > -- > Ken Matsui
