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

[Jakub Jelinek]

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?
  int x = std::bit_cast (T, d).a; // Similarly for default copy assignment operators...
  int y = std::bit_cast (T, e).a; // And this too?
  int z = std::bit_cast (T, S ()).a; // This one is well defined?
  return u + v + w + x + y + z;
}

constexpr int x = foo ();

	Jakub