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
