On Thu, 27 Aug 2020, 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.
Note we've basically settled on that SRA needs to copy padding and that
GIMPLE copies all bytes for aggregate copies and thus
x = {}
is equivalent to a memset.
> 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.
Now indeed the gimplifier will turn a aggregate CTOR initialization
to memberwise init without caring for padding. Which means GENERIC
has the less strict semantics and we indeed would need some CTOR flag
to tell whether padding is implicitely zero or undefined?
> 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
>
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
