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

["arthur.j.odwyer at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #23 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> ---
(In reply to Jonathan Wakely from comment #22)
> 
> Richi suggested that we could avoid these runtime branches (which hurt
> optimization, see PR 109445) if we knew how many bytes of tail padding there
> are in _Tp [...]
> We don't have a built-in to tell us the number of [trailing] padding bytes, but we
> might be able to use something like this

Three thoughts that might be helpful:
- There may be padding in the middle of an object, and I'm not confident that
the Standard actually forbids it from being used. Of course your approach works
fine on the Itanium ABI, and probably works everywhere that actually exists. If
you've got chapter+verse proving that it must work *everywhere*, I'd appreciate
seeing it, just for my own information.
- If GCC were ever to add a builtin for this notion, IMO the proper name would
be `__datasizeof(T)`. See
https://danakj.github.io/2023/01/15/trivially-relocatable.html#data-size
- You can implement your library trait like this; see
https://quuxplusone.github.io/blog/2023/03/04/trivial-swap-prize-update/#step-1.-std-swap-can-t-assume-it

    template <class _Tp>
    struct __libcpp_datasizeof {
        struct _Up {
            [[__no_unique_address__]] _Tp __t_;
            char __c_;
        };
        static const size_t value = __builtin_offsetof(_Up, __c_);
    };

Unfortunately it looks like GCC doesn't support
`__attribute__((__no_unique_address__))` in C++03 mode. (Neither does Clang.
What is up with that!)

Your suggested trait implementation is slightly wrong for `is_final` types: you
return 0 but really a final type _can_ have usable tail padding. See
https://godbolt.org/z/P6x459MEq