On Fri, Nov 08, 2024 at 10:29:09AM +0100, Jakub Jelinek wrote:
> 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?
And there is another thing I'm unsure about, what happens in a union which
is zero-initialized and has padding bits if the active member is changed
(especially in constant evaluation). Are all padding bits invalidated
through that, or something else?
Jakub
