From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 69B413858D38; Mon, 20 Feb 2023 08:38:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 69B413858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1676882301; bh=p3t81IzXdCtiEW0dpIpM0R+/g02K2mnLc4XEYd7uF5s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=D+VfsLK2wmElav3iOr11wLDZuopGJ4qfPHrnwrRfzYlIg91N+t93jb4W5eLIqXPMz 4ir4d4fMxDKauv4h4XWF2C3bAXUU7i0Fn4rkE8HcbaHWTNq+OXiNR8CyzyEkD9C2zj eBvJ89Zwfqvh9+0i5/t5+skdceC/8Be6uyq7kRrk= From: "de34 at live dot cn" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/108846] std::copy, std::copy_n on potentially overlapping subobjects Date: Mon, 20 Feb 2023 08:38:19 +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: 13.0 X-Bugzilla-Keywords: ABI X-Bugzilla-Severity: normal X-Bugzilla-Who: de34 at live dot cn 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: cc 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108846 Jiang An changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |de34 at live dot cn --- Comment #4 from Jiang An --- (In reply to Andrew Pinski from comment #2) > Related to https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2= 403 > but instead of language, it is the library methods. CWG2403 looks like an unfortunate result of ABI design. If any non-padding byte of a potentially-overlapping subobject X is actually overlapping with a padding byte of subobject Y, Y should be initialized bef= ore X, because all bytes of Y may be written in initialization. However, on Ita= nium ABI virtual base class subobjects violate such intuitive rule. But I think it's only closedly related to uninitialized memory algorithms (which perform initialization instead of assignment), and there's already a note saying that it's UB to use them to initialize potentially-overlapping objects ([specialized.algorithms.general]/3). (In reply to Andrew Pinski from comment #3) > Even https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2544 is > very much related. (As the submitter) I think this issue only legitimates current implementati= on of pointer arithmetic. For example, assuming both sizeof(B) and sizeof(D) are 8, which means the l= ast 2 bytes of B are padding (true for common implementations on Itanium ABI): struct B { int32_t x; int16_t y; }; struct D : B { int16_t z; }; The current wording in [basic.compound]/3 requires that given `B b{};` and = `D d{};`, `static_cast(&d) + 1` represents the address of the byte at offs= et 6, which is almost unimplementable. However, subtraction between pointers are performed as usual for even for potentially-overlapping subobjects, which is correctly implemented. In the case of copy family algorithms, I believe it's OK to specially handle cases where last - first =3D=3D 1. BTW, there's CWG2527 that is closed as NAD, which seemingly means that an a= rray subobject can be potentially-overlapping, even if element subobjects can't.=