From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BA06C385841F; Thu, 24 Feb 2022 12:19:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BA06C385841F From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types Date: Thu, 24 Feb 2022 12:19:53 +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: 5.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: redi at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 12:19:53 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D68350 Jonathan Wakely changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|ville.voutilainen at gmail dot com |redi at gcc dot gnu= .org --- Comment #9 from Jonathan Wakely --- (In reply to Barry Revzin from comment #8) > Whereas the copy_b case could also use memmove. I'd been working on the assumption that it can't, because for types that ar= en't trivially default constructible we need a constructor to begin the lifetime. But the rules for implicit-lifetime class types only require at least one trivial constructor and a trivial destructor, so a trivial copy constructor= is enough. And memcpy/memmove implicitly create objects in the destination storage. I don't think that was really explicit before the implicit-lifetime rules in C++20. The example in C++17 [basic.types] p3 implies that the destination doesn't need to be an initialized object, but nothing said that normatively. Quite the opposite: C++17 [basic.life] seems clear that initialisation must= be done for types with non-vacuous initialization (such as Barry's type B), and nothing in C++17 said that memcpy/memmove do any initialization. C++20 is c= lear though. So: - If the input and output type are the same size and both are trivially constructible, we can use memcpy. We should call memcpy directly from std::uninitialized_copy rather than via std::copy, because std::copy does= n't allow overlapping ranges, and has to use memmove instead. - If the output type is trivially default constructible and is assignable f= rom the input type, we can use std::copy (but it's unclear whether that gives= any benefit if we can't turn it into memcpy/memmove). - Otherwise, just use std::construct_at on each element. I have a patch, but it's for stage 1 not GCC 12.=