[Bug libstdc++/108846] std::copy, std::copy_n on potentially overlapping subobjects

["de34 at live dot cn" <gcc-bugzilla@gcc.gnu.org>]

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

Jiang An <de34 at live dot cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |de34 at live dot cn

--- Comment #4 from Jiang An <de34 at live dot cn> ---
(In reply to Andrew Pinski from comment #2)
> Related to https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2403
> 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 before
X, because all bytes of Y may be written in initialization. However, on Itanium
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 implementation
of pointer arithmetic.

For example, assuming both sizeof(B) and sizeof(D) are 8, which means the last
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<B*>(&d) + 1` represents the address of the byte at offset
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 == 1.


BTW, there's CWG2527 that is closed as NAD, which seemingly means that an array
subobject can be potentially-overlapping, even if element subobjects can't.