[v2,1/2] libstdc++: Fix error handling in filesystem::equivalent [PR113250]

  This patch made std::filesystem::equivalent correctly throw an exception
when either path does not exist as per [fs.op.equivalent]/4.

libstdc++-v3/ChangeLog:

	* src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&.
	* src/filesystem/ops.cc (fs::equivalent): Likewise.
	* testsuite/27_io/filesystem/operations/equivalent.cc: Handle
	error codes.
	* testsuite/experimental/filesystem/operations/equivalent.cc:
	Likewise.

Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org>
---
 libstdc++-v3/src/c++17/fs_ops.cc                              | 2 +-
 libstdc++-v3/src/filesystem/ops.cc                            | 2 +-
 .../testsuite/27_io/filesystem/operations/equivalent.cc       | 4 ++--
 .../experimental/filesystem/operations/equivalent.cc          | 4 ++--
 4 files changed, 6 insertions(+), 6 deletions(-)
  

On Thu, 11 Jan 2024 at 09:43, Ken Matsui <kmatsui@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).


>
> libstdc++-v3/ChangeLog:
>
>         * src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&.
>         * src/filesystem/ops.cc (fs::equivalent): Likewise.
>         * testsuite/27_io/filesystem/operations/equivalent.cc: Handle
>         error codes.
>         * testsuite/experimental/filesystem/operations/equivalent.cc:
>         Likewise.
>
> Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org>
> ---
>  libstdc++-v3/src/c++17/fs_ops.cc                              | 2 +-
>  libstdc++-v3/src/filesystem/ops.cc                            | 2 +-
>  .../testsuite/27_io/filesystem/operations/equivalent.cc       | 4 ++--
>  .../experimental/filesystem/operations/equivalent.cc          | 4 ++--
>  4 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
> index e0b308a37ea..61df19753ef 100644
> --- a/libstdc++-v3/src/c++17/fs_ops.cc
> +++ b/libstdc++-v3/src/c++17/fs_ops.cc
> @@ -897,7 +897,7 @@ fs::equivalent(const path& p1, const path& p2, error_code& ec) noexcept
>        return st1.st_dev == st2.st_dev && st1.st_ino == st2.st_ino;
>  #endif
>      }
> -  else if (!exists(s1) && !exists(s2))
> +  else if (!exists(s1) || !exists(s2))
>      ec = std::make_error_code(std::errc::no_such_file_or_directory);
>    else if (err)
>      ec.assign(err, std::generic_category());
> diff --git a/libstdc++-v3/src/filesystem/ops.cc b/libstdc++-v3/src/filesystem/ops.cc
> index eccdae3d910..4d23a804da0 100644
> --- a/libstdc++-v3/src/filesystem/ops.cc
> +++ b/libstdc++-v3/src/filesystem/ops.cc
> @@ -765,7 +765,7 @@ fs::equivalent(const path& p1, const path& p2, error_code& ec) noexcept
>         return false;
>        return st1.st_dev == st2.st_dev && st1.st_ino == st2.st_ino;
>      }
> -  else if (!exists(s1) && !exists(s2))
> +  else if (!exists(s1) || !exists(s2))
>      ec = std::make_error_code(std::errc::no_such_file_or_directory);
>    else if (err)
>      ec.assign(err, std::generic_category());
> diff --git a/libstdc++-v3/testsuite/27_io/filesystem/operations/equivalent.cc b/libstdc++-v3/testsuite/27_io/filesystem/operations/equivalent.cc
> index 78f6e368204..68f32366d65 100644
> --- a/libstdc++-v3/testsuite/27_io/filesystem/operations/equivalent.cc
> +++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/equivalent.cc
> @@ -34,13 +34,13 @@ test01()
>    bool result;
>
>    result = equivalent(p1, p2, ec);
> -  VERIFY( ec );
> +  VERIFY( ec == std::errc::no_such_file_or_directory );
>    VERIFY( !result );
>
>    __gnu_test::scoped_file f1(p1);
>    ec = bad_ec;
>    result = equivalent(p1, p2, ec);
> -  VERIFY( !ec );
> +  VERIFY( ec == std::errc::no_such_file_or_directory );
>    VERIFY( !result );
>
>    __gnu_test::scoped_file f2(p2);
> diff --git a/libstdc++-v3/testsuite/experimental/filesystem/operations/equivalent.cc b/libstdc++-v3/testsuite/experimental/filesystem/operations/equivalent.cc
> index 929a6ca8609..5bc477a31cd 100644
> --- a/libstdc++-v3/testsuite/experimental/filesystem/operations/equivalent.cc
> +++ b/libstdc++-v3/testsuite/experimental/filesystem/operations/equivalent.cc
> @@ -35,13 +35,13 @@ test01()
>    bool result;
>
>    result = equivalent(p1, p2, ec);
> -  VERIFY( ec );
> +  VERIFY( ec == std::errc::no_such_file_or_directory );
>    VERIFY( !result );
>    const auto bad_ec = ec;
>
>    __gnu_test::scoped_file f1(p1);
>    result = equivalent(p1, p2, ec);
> -  VERIFY( !ec );
> +  VERIFY( ec == std::errc::no_such_file_or_directory );
>    VERIFY( !result );
>
>    __gnu_test::scoped_file f2(p2);
> --
> 2.43.0
>
  

On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely <jwakely@redhat.com> wrote:
> On Thu, 11 Jan 2024 at 09:43, Ken Matsui <kmatsui@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

Do we basically want to git checkout & gcc-backport for each branch
after this patch is committed to the trunk?

> 
> >
> > libstdc++-v3/ChangeLog:
> >
> >         * src/c++17/fs_ops.cc (fs::equivalent): Use || instead of &&.
> >         * src/filesystem/ops.cc (fs::equivalent): Likewise.
> >         * testsuite/27_io/filesystem/operations/equivalent.cc: Handle
> >         error codes.
> >         * testsuite/experimental/filesystem/operations/equivalent.cc:
> >         Likewise.
> >
> > Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org>
> > ---
> >  libstdc++-v3/src/c++17/fs_ops.cc                              | 2 +-
> >  libstdc++-v3/src/filesystem/ops.cc                            | 2 +-
> >  .../testsuite/27_io/filesystem/operations/equivalent.cc       | 4 ++--
> >  .../experimental/filesystem/operations/equivalent.cc          | 4 ++--
> >  4 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
> > index e0b308a37ea..61df19753ef 100644
> > --- a/libstdc++-v3/src/c++17/fs_ops.cc
> > +++ b/libstdc++-v3/src/c++17/fs_ops.cc
> > @@ -897,7 +897,7 @@ fs::equivalent(const path& p1, const path& p2, error_code& ec) noexcept
> >        return st1.st_dev == st2.st_dev && st1.st_ino == st2.st_ino;
> >  #endif
> >      }
> > -  else if (!exists(s1) && !exists(s2))
> > +  else if (!exists(s1) || !exists(s2))
> >      ec = std::make_error_code(std::errc::no_such_file_or_directory);
> >    else if (err)
> >      ec.assign(err, std::generic_category());
> > diff --git a/libstdc++-v3/src/filesystem/ops.cc b/libstdc++-v3/src/filesystem/ops.cc
> > index eccdae3d910..4d23a804da0 100644
> > --- a/libstdc++-v3/src/filesystem/ops.cc
> > +++ b/libstdc++-v3/src/filesystem/ops.cc
> > @@ -765,7 +765,7 @@ fs::equivalent(const path& p1, const path& p2, error_code& ec) noexcept
> >         return false;
> >        return st1.st_dev == st2.st_dev && st1.st_ino == st2.st_ino;
> >      }
> > -  else if (!exists(s1) && !exists(s2))
> > +  else if (!exists(s1) || !exists(s2))
> >      ec = std::make_error_code(std::errc::no_such_file_or_directory);
> >    else if (err)
> >      ec.assign(err, std::generic_category());
> > diff --git a/libstdc++-v3/testsuite/27_io/filesystem/operations/equivalent.cc b/libstdc++-v3/testsuite/27_io/filesystem/operations/equivalent.cc
> > index 78f6e368204..68f32366d65 100644
> > --- a/libstdc++-v3/testsuite/27_io/filesystem/operations/equivalent.cc
> > +++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/equivalent.cc
> > @@ -34,13 +34,13 @@ test01()
> >    bool result;
> >
> >    result = equivalent(p1, p2, ec);
> > -  VERIFY( ec );
> > +  VERIFY( ec == std::errc::no_such_file_or_directory );
> >    VERIFY( !result );
> >
> >    __gnu_test::scoped_file f1(p1);
> >    ec = bad_ec;
> >    result = equivalent(p1, p2, ec);
> > -  VERIFY( !ec );
> > +  VERIFY( ec == std::errc::no_such_file_or_directory );
> >    VERIFY( !result );
> >
> >    __gnu_test::scoped_file f2(p2);
> > diff --git a/libstdc++-v3/testsuite/experimental/filesystem/operations/equivalent.cc b/libstdc++-v3/testsuite/experimental/filesystem/operations/equivalent.cc
> > index 929a6ca8609..5bc477a31cd 100644
> > --- a/libstdc++-v3/testsuite/experimental/filesystem/operations/equivalent.cc
> > +++ b/libstdc++-v3/testsuite/experimental/filesystem/operations/equivalent.cc
> > @@ -35,13 +35,13 @@ test01()
> >    bool result;
> >
> >    result = equivalent(p1, p2, ec);
> > -  VERIFY( ec );
> > +  VERIFY( ec == std::errc::no_such_file_or_directory );
> >    VERIFY( !result );
> >    const auto bad_ec = ec;
> >
> >    __gnu_test::scoped_file f1(p1);
> >    result = equivalent(p1, p2, ec);
> > -  VERIFY( !ec );
> > +  VERIFY( ec == std::errc::no_such_file_or_directory );
> >    VERIFY( !result );
> >
> >    __gnu_test::scoped_file f2(p2);
> > --
> > 2.43.0
> >
>
  

On Thu, 11 Jan 2024 at 10:56, Ken Matsui <kmatsui@gcc.gnu.org> wrote:
>
> On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely <jwakely@redhat.com> wrote:
> > On Thu, 11 Jan 2024 at 09:43, Ken Matsui <kmatsui@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).
  

On Thu, 11 Jan 2024 at 11:14, Jonathan Wakely <jwakely@redhat.com> wrote:
> On Thu, 11 Jan 2024 at 10:56, Ken Matsui <kmatsui@gcc.gnu.org> wrote:
> >
> > On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely <jwakely@redhat.com> wrote:
> > > On Thu, 11 Jan 2024 at 09:43, Ken Matsui <kmatsui@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.
  

On Thu, Jan 11, 2024 at 3:45 AM Ken Matsui <kmatsui@cs.washington.edu> wrote:
>
> On Thu, 11 Jan 2024 at 11:14, Jonathan Wakely <jwakely@redhat.com> wrote:
> > On Thu, 11 Jan 2024 at 10:56, Ken Matsui <kmatsui@gcc.gnu.org> wrote:
> > >
> > > On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely <jwakely@redhat.com> wrote:
> > > > On Thu, 11 Jan 2024 at 09:43, Ken Matsui <kmatsui@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
  

On Thu, 11 Jan 2024 at 12:23, Ken Matsui <kmatsui@gcc.gnu.org> wrote:
>
> On Thu, Jan 11, 2024 at 3:45 AM Ken Matsui <kmatsui@cs.washington.edu> wrote:
> >
> > On Thu, 11 Jan 2024 at 11:14, Jonathan Wakely <jwakely@redhat.com> wrote:
> > > On Thu, 11 Jan 2024 at 10:56, Ken Matsui <kmatsui@gcc.gnu.org> wrote:
> > > >
> > > > On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely <jwakely@redhat.com> wrote:
> > > > > On Thu, 11 Jan 2024 at 09:43, Ken Matsui <kmatsui@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

Yes, please close as RESOLVED FIXED and set the target milestone to
the first release with the fix, which will be 11.5

In cases like this where the fix is backported to multiple release
branches I also add a comment to say "fixed in 11.5, 12.4, 13.3"
because otherwise just setting the target milestone to 11.5 doesn't
tell you about the other branches.

It's also nice to thank the reporter for filing it, especially when
they identify the root cause and suggest a fix.

And thank you for taking care of it!
  

On Thu, Jan 11, 2024 at 4:27 AM Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Thu, 11 Jan 2024 at 12:23, Ken Matsui <kmatsui@gcc.gnu.org> wrote:
> >
> > On Thu, Jan 11, 2024 at 3:45 AM Ken Matsui <kmatsui@cs.washington.edu> wrote:
> > >
> > > On Thu, 11 Jan 2024 at 11:14, Jonathan Wakely <jwakely@redhat.com> wrote:
> > > > On Thu, 11 Jan 2024 at 10:56, Ken Matsui <kmatsui@gcc.gnu.org> wrote:
> > > > >
> > > > > On Thu, 11 Jan 2024 at 10:46, Jonathan Wakely <jwakely@redhat.com> wrote:
> > > > > > On Thu, 11 Jan 2024 at 09:43, Ken Matsui <kmatsui@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
>
> Yes, please close as RESOLVED FIXED and set the target milestone to
> the first release with the fix, which will be 11.5
>
> In cases like this where the fix is backported to multiple release
> branches I also add a comment to say "fixed in 11.5, 12.4, 13.3"
> because otherwise just setting the target milestone to 11.5 doesn't
> tell you about the other branches.
>
> It's also nice to thank the reporter for filing it, especially when
> they identify the root cause and suggest a fix.
>
> And thank you for taking care of it!
>
Done!  I truly appreciate your kind step-by-step guidance!