-initialized)
state.
We could probably still do the truncation, but clear the
CONSTRUCTOR_NO_CLEARING flag on the element initializer.
Ah, this seems to work well. Like this?
-- >8 --
Subject: [PATCH] c++: cxx_eval_vec_init after zero initialization
[PR96282]
In the first testcase belo
s truncate
> > > > > > > ctx->ctor beforehand, not just when the RANGE_EXPR optimization
> > > > > > > applies.
> > > > > > > If it's true that the initializer of a VEC_INIT_EXPR can't observe
> > > > > > &
UCTOR_NO_CLEARING flag on the element initializer.
Ah, this seems to work well. Like this?
-- >8 --
Subject: [PATCH] c++: cxx_eval_vec_init after zero initialization [PR96282]
In the first testcase below, expand_aggr_init_1 sets up t's default
constructor such that the ctor first zero-i
t; > > truncate I think?
> > > >
> > > > What if default-initialization of the array element type doesn't fully
> > > > initialize the elements, e.g. if 'e' had another member without a
> > > > default
> > > &g
ult
> > > initializer? Does truncation first mean we lose the zero-initialization
> > > of
> > > such a member?
> >
> > Hmm, it looks like we would lose the zero-initialization of such a
> > member with or without truncation first (so with any one o
evaluation loop in
cxx_eval_vec_init disregards each element's prior (zero-initialized)
state.
We could probably still do the truncation, but clear the
CONSTRUCTOR_NO_CLEARING flag on the element initializer.
Ah, this seems to work well. Like this?
-- >8 --
Subject: [PATCH] c++:
ne of the three
proposed fixes). I think it's because the evaluation loop in
cxx_eval_vec_init disregards each element's prior (zero-initialized)
state.
>
> We could probably still do the truncation, but clear the
> CONSTRUCTOR_NO_CLEARING flag on the element initializer.
Ah,
On 8/3/20 8:53 AM, Patrick Palka wrote:
On Mon, 3 Aug 2020, Patrick Palka wrote:
In the first testcase below, expand_aggr_init_1 sets up t's default
constructor such that the ctor first zero-initializes the entire base b,
followed by calling b's default constructor, the latter of which just
def
On Mon, 3 Aug 2020, Patrick Palka wrote:
> In the first testcase below, expand_aggr_init_1 sets up t's default
> constructor such that the ctor first zero-initializes the entire base b,
> followed by calling b's default constructor, the latter of which just
> default-initializes the array member b
In the first testcase below, expand_aggr_init_1 sets up t's default
constructor such that the ctor first zero-initializes the entire base b,
followed by calling b's default constructor, the latter of which just
default-initializes the array member b::m via a VEC_INIT_EXPR.
So upon constexpr evalua
10 matches
Mail list logo
