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.
