https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117256
--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:fd62fdc5e1b3c4baf5218eedbc3c6d29861f027b commit r15-5747-gfd62fdc5e1b3c4baf5218eedbc3c6d29861f027b Author: Jakub Jelinek <ja...@redhat.com> Date: Thu Nov 28 11:30:32 2024 +0100 c++: Small initial fixes for zeroing of padding bits [PR117256] https://eel.is/c++draft/dcl.init#general-6 says that even padding bits are supposed to be zeroed during zero-initialization. The following patch on top of the https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665565.html patch attempts to implement that, though only for the easy cases so far, in particular marks the CONSTRUCTOR created during zero-initialization (or zero-initialization done during the value-initialization) as having padding bits cleared and for constexpr evaluation attempts to preserve that bit on a new CONSTRUCTOR created for CONSTRUCTOR_ZERO_PADDING_BITS lhs. I think we need far more than that, but am not sure where exactly to implement that. In particular, I think __builtin_bitcast should take it into account during constant evaluation, if the padding bits in something are guaranteed to be zero, then I'd think std::bitcast out of it and testing those bits in there should be well defined. But if we do that, the flag needs to be maintained precisely, not just conservatively, so e.g. any place where some object is copied into another one (except bitcast?) which would be element-wise copy, the bit should be cleared (or preserved from the earlier state? I'd hope element-wise copying invalidates even the padding bits, but then what about just stores into some members, do those invalidate the padding bits in the rest of the object?). But if it is an elided copy, it shouldn't. And am not really sure what happens e.g. with non-automatic constexpr variables. If it is constructed by something that doesn't guarantee the zeroing of the padding bits (so similarly constructed constexpr automatic variable would have undefined state of the padding bits), are those padding bits well defined because it isn't automatic variable? Anyway, I hope the following patch is at least a small step in the right direction. 2024-11-28 Jakub Jelinek <ja...@redhat.com> PR c++/78620 PR c++/117256 * init.cc (build_zero_init_1): Set CONSTRUCTOR_ZERO_PADDING_BITS. (build_value_init_noctor): Likewise. * constexpr.cc (cxx_eval_store_expression): Propagate CONSTRUCTOR_ZERO_PADDING_BITS flag.
