On Wed, Sep 03, 2025 at 03:23:39PM +0000, Qing Zhao wrote:
>
>
> > On Sep 3, 2025, at 09:38, Jakub Jelinek <ja...@redhat.com> wrote:
> >
> > On Tue, Sep 02, 2025 at 09:35:04PM +0000, Qing Zhao wrote:
> >>> I think I've mentioned it earlier, but -ftrivial-auto-var-init= doesn't
> >>> work at all for C++.
> >> You mean that -ftrivial-auto-var-init hasn’t work at all for C++’s auto
> >> variables with non-trivial ctors?
> >
> > Yeah. Actually, it probably also works if non-trivial ctors are constexpr
> > and the ctors are actually optimized into TREE_CONSTANT DECL_INITIALIZER.
>
> For such case, the CLOBBER (bob) is not emitted?
Nope. Consider
struct S { S () : a (42) {} int a, b, c; };
struct T : S { T () : d (43) {} int d, e, f; };
struct U : virtual S { U () : g (44) {} int g, h, i; };
struct V : virtual U, T { V () : j (45) {} int j, k, l; };
struct W { int a, b; char c; long long d; };
struct X { constexpr X () : a (1), b (2), c (3), d (4) {} int a, b; char c;
long long d; };
void bar (S &, T &, V &, int &, W &, X &);
int
foo ()
{
S s;
T t;
V v;
int i;
int j;
W k = { 1, 2, 3, 4 };
X l;
bar (s, t, v, i, k, l);
return j;
}
Both k and l variables are initialized there with DECL_INITIAL and no
CLOBBER (bob) is emitted for those.
> You mean, under the new AUTO_INIT_CXX26 mode, ONLY all the fields of the
> structure
> are zero initialized, but leave the paddings uninitialized?
Possibly uninitialized, yes. So, there is no need for
__builtin_clear_padding after the DECL_INITIAL initializers even if they
have padding, that is still UB, not EB. Of course,
-ftrivial-auto-var-init={zero,pattern} can override that.
> > Plus as Jason said, move the CLOBBER_OBJECT_BEGIN clobbers from ctors for
> > flag_auto_var_init != AUTO_INIT_UNINITIALIZED && flag_lifetime_dse > 1
> > to before the whole object is initialized in all places where we emit calls
> > to the non-trivial ctors and if it initializes a VAR_DECL (rather than say
> > heap) emit .DEFERRED_INIT calls after those.
>
> A little confused with the above:
>
> Currently, we have the following IR (t.cc <http://t.cc/>.006t.gimple): (with
> -ftrivial-auto-var-init=zero)
>
> Int foo ()
> {
> struct S s;
> …
> try
> {
> s = .DEFERRED_INIT (12, 2, &"s"[0]);
> S::S (&s);
> …
> }
>
> void S::S (struct S * const this)
> {
> *this = {CLOBBER(bob)};
> {
> this->a = 42;
> }
> }
>
> Will the suggested new IR for the above be the following?
>
> Int foo ()
> {
> struct S s;
> …
> try
> {
> s = {CLOBBER(bob));
> S::S (&s);
> s = .DEFFERRED_INIT (12, 2, &”s”[0]);
Nope, that would be wrong. It should be either
s = {CLOBBER(bob));
s = .DEFFERRED_INIT (12, 2, &”s”[0]);
S::S (&s);
or perhaps just
s = .DEFFERRED_INIT (12, 2, &”s”[0]);
S::S (&s);
in that case, .DEFERRED_INIT also has the effect of throwing away old
content.
> void S::S (struct S * const this)
> {
> this->a = 42;
> }
>
> Or something else?
And sure, removing the CLOBBER(bob) from the ctors.
> Okay, so [[indeterminate]] is a new attribute that will attached to the
> variables, meaning
> that the value of the variable is intended to be indeterminate?
Yes, just [[indeterminate]] being a standard way to express that,
uninitialized being a GNU extension.
Jakub
