From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id BE1813858C5F; Fri,  3 Feb 2023 09:32:50 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE1813858C5F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1675416770;
	bh=hXPIaWgkNwvxQvaAn2osqyhOXH3dQCwBS0j21kR3Pck=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=rnHiDo3C6HUNzB2UEeLl7VsVEwzwD2sgFZsjUML6B58iWp5Tg8K1MZMQJDKAe6CQS
	 ekt9tuUI2WqjjWxewBRiNG9DwDPdSZrIbQGW9WGdqbAeBZFzGmLhLeY3OfyMGP9F/K
	 fBfabq48keR8Dn2HHUX+vvRRCK/aUsaKYIi3qHbM=
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/108645] Change in behavior, std::accumulate doesn't
 always work as expected in C++20 builds
Date: Fri, 03 Feb 2023 09:32:49 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108645-4-ZPgBrDxhm3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108645-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108645-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108645

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Evan Teran from comment #1)
> Which results in the same behavior, so it appears to be that the:
>=20
> ```
> basic_string operator+(basic_string &&, basic_string &&)
> ```
>=20
> Overload doesn't steal the guts of the rhs at all?

It does if:
- the allocators are equal,
- the LHS does not have sufficient capacity for the result, and
- the RHS does have sufficient capacity for the result.

In your example, all your strings fit in the SSO buffer inside the std::str=
ing
object, so the LHS has sufficient capacity for the result. And there's noth=
ing
to steal from the RHS anyway, as it doesn't own any allocated memory.

The observed behaviour is not a bug, because as you say, leaving the RHS
non-empty is a valid state. The implementation is pretty clear:

    {
#if _GLIBCXX_USE_CXX11_ABI
      using _Alloc_traits =3D allocator_traits<_Alloc>;
      bool __use_rhs =3D false;
      if _GLIBCXX17_CONSTEXPR (typename _Alloc_traits::is_always_equal{})
        __use_rhs =3D true;
      else if (__lhs.get_allocator() =3D=3D __rhs.get_allocator())
        __use_rhs =3D true;
      if (__use_rhs)
#endif
        {
          const auto __size =3D __lhs.size() + __rhs.size();
          if (__size > __lhs.capacity() && __size <=3D __rhs.capacity())
            return std::move(__rhs.insert(0, __lhs));
        }
      return std::move(__lhs.append(__rhs));
    }

If the RHS object is used (because all the conditions above are true) then =
it
will be moved into the return value and so left empty.

If the LHS is used then the RHS is unchanged.=