> > My intuition is that you could get those guarantees if you ran
> > std::clear_padding, std::memcpy to a byte array, and then std::bit_cast
> out
> > of a byte array into std::uint128_t. However, that forces compilers to
> > permanently spill objects from registers (such as function parameters
> > passed via register) into memory when std::clear_padding is used on them
> > because it's possible that someone will later read the padding bits.
> Maybe
> > merely the possibility that std::clear_padding is run in some opaque
> > function causes pessimizations. This would definitely need to be
> > investigated when proposing a std::clear_padding function.
>
> No, it does not. Again, the only thing that matters is the behaviour.
>
> The compiler does not have to make the variable concrete in memory.
>

But behavior needs to be implemented in some fashion, and specifying
certain behavior constrains what implementations are possible, sometimes in
surprising ways.

If you receive a long double function parameter and your calling
conventions are so that this is passed via floating-point stack, there are
no padding bits in that object which could be cleared. Ergo, if you ran
std::clear_padding, this would require spilling the object from the
floating-point stack into memory so that the padding bits can be accessed
later, with the guaranteed cleared value.

To be fair, I don't think std::clear_padding creates this problem; you can
already memcpy into an object to manipulate its padding bits, so the
problem starts with padding bits being observable. However, use of
clear_padding and memcpy idioms may pessimize code in practice, so perhaps
that's not an idiom we want to promote.

By comparison, std::bit_cast_clear_padding ignores the values of input
padding bits, so the compiler would never be required to track their values.