Re: [PATCH] c++: Add __builtin_bit_cast to implement std::bit_cast [PR93121]

[Jonathan Wakely <jwakely@redhat.com>]

On 27/08/20 12:06 +0200, Jakub Jelinek wrote:
>On Fri, Jul 31, 2020 at 04:28:05PM -0400, Jason Merrill via Gcc-patches wrote:
>> On 7/31/20 6:06 AM, Jakub Jelinek wrote:
>> > On Fri, Jul 31, 2020 at 10:54:46AM +0100, Jonathan Wakely wrote:
>> > > > Does the standard require that somewhere?  Because that is not what the
>> > > > compiler implements right now.
>> > >
>> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78620
>> >
>> > But does that imply that all CONSTRUCTORs without CONSTRUCTOR_NO_CLEARING
>> > need to be treated that way?  I mean, aren't such CONSTRUCTORs used also for
>> > other initializations?
>>
>> Yes, they are also used to represent constant values of classes that are
>> initialized by constexpr constructor.
>>
>> > And, are the default copy constructors or assignment operators supposed to
>> > also copy the padding bits, or do they become unspecified again through
>> > that?
>>
>> For a non-union class, a defaulted copy is defined as memberwise copy, not a
>> copy of the entire object representation.  So I guess strictly speaking the
>> padding bits do become unspecified.  But I think if the copy is trivial, in
>> practice all implementations do copy the object representation; perhaps the
>> specification should adjust accordingly.
>
>Sorry for not responding earlier.  I think at least in GCC there is no
>guarantee the copying is copying the object representation rather than
>memberwise copy, both are possible, depending e.g. whether SRA happens or
>not.
>
>So, shouldn't we have a new CONSTRUCTOR flag that will represent whether
>padding bits are cleared or not and then use it e.g. in the gimplifier?
>Right now the gimplifier only adds first zero initialization if
>CONSTRUCTOR_NO_CLEARING is not set and some initializers are not present,
>so if there is a new flag, we'd need to in that case find out if there are
>any padding bits and do the zero initialization in that case.
>A question is if GIMPLE var = {}; statement (empty CONSTRUCTOR) is handled
>as zero initialization of also the padding bits, or if we should treat it
>that way only if the CONSTRUCTOR on the rhs has the new bit set and e.g.
>when lowering memset 0 into var = {}; set the bit too.
From what I understood on IRC, D has similar need for zero initialization of
>padding.
>
>In the testcase below, what is and what is not UB?
>
>#include <bit>
>
>struct S { int a : 31; 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?
>  int v = std::bit_cast (T, b).a; // But this is invalid, right?  There is no difference in the IL though.
>  int w = std::bit_cast (T, c).a; // And this is also invalid, or are default copy ctors required to copy padding bits?

They are not required to. It does a memberwise copy of the bases and
members. Padding is not copied.

>  int x = std::bit_cast (T, d).a; // Similarly for default copy assignment operators...

Same again, memberwise assignment of the bases and members.

I'm not sure whether the previous values of padding bits has to be
preserved though. If the LHS was zero-initialized (so its padding bits
were zeroed) and you assign to it, I don't see anything that allows
the padding bits to change. But I don't think the intention is to
forbid using memcpy for trivial assignments, and that would copy
padding bits.

>  int y = std::bit_cast (T, e).a; // And this too?

Yes. I don't think e = S() is required to change the padding bits of
e to be copies of the zero bits in S(), so they are unspecified after
that assignment, and after the bit_cast.

>  int z = std::bit_cast (T, S ()).a; // This one is well defined?

Yes, I think so.

>  return u + v + w + x + y + z;
>}
>
>constexpr int x = foo ();
>
>	Jakub