On Thu, Aug 27, 2020 at 12:06:59PM +0100, Jonathan Wakely wrote: > On 27/08/20 12:46 +0200, Jakub Jelinek wrote: > > On Thu, Aug 27, 2020 at 12:06:13PM +0200, Jakub Jelinek via Gcc-patches > > wrote: > > > > Oops, rewrote the testcase from __builtin_bit_cast to std::bit_cast without > > adjusting the syntax properly. > > Also, let's not use bitfields in there, as clang doesn't support those. > > So, adjusted testcase below. clang++ rejects all 6 of those, but from what > > you said, I'd expect that u and z should be well defined. > > > > #include <bit> > > > > struct S { short a; int b; }; > > struct T { int a, b; }; > > > > constexpr int > > foo () > > { > > S a = S (); > > S b = { 0, 0 }; > > S c = a; > > S d; > > S e; > > d = a; > > e = S (); > > int u = std::bit_cast<T> (a).a; // Is this well defined due to value > > initialization of a? > > The standard says that padding bits in the bit_cast result are > unspecified, so I don't think they have to be copied even if the > source object was zero-initialized and has all-zero padding bits.
My understanding of "Padding bits of the To object are unspecified." is that one shouldn't treat the result of std::bit_cast as if it was e.g. value initialization followed by member-wise assignment. But it doesn't say anything about padding bits in the From object. In the above testcase, T has no padding bits, only S has them. I think the "Padding bits of the To object are unspecified." should be about: T t = { 0, 0 }; int s = std::bit_cast<T> (std::bit_cast<S> (t)).a; being UB, that one can't expect the padding bits in S to have a particular value. Jakub