https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102401
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #3) > There are things that need to be clarified, in particular value > initialization should clear even the padding bits, so supposedly > std::bit_cast of Item() if the NSDMIs would be dropped might be well defined > and ok in constexpr contexts (we don't implement that currently, and don't > implement it even at runtime, we treat padding bits as always undefined), I think that's a bug. > but the above testcase has a user defined constructor and therefore no zero No it doesn't. It has no constructor that is user-declared, so a default constructor is implicitly defined as defaulted. That default constructor is non-trivial (because of the default member-initializers) but it's still implicitly defined. List-initialization with an empty init list means value-initialization. Since there is no user-provided default constructor, that means: "the object is zero-initialized and the semantic constraints for default-initialization are checked, and if T has a non-trivial default constructor, the object is default-initialized;" So it should be zero-initialized (which zeroes all padding) and then it should be default-initialized (which uses the implicitly-defined default constructor, which uses the NSDMIs). So the padding bits should be initialized, no?
