> On Sep 3, 2025, at 12:32, Jakub Jelinek <[email protected]> wrote:
>
> On Wed, Sep 03, 2025 at 03:23:39PM +0000, Qing Zhao wrote:
>>
>>
>>> On Sep 3, 2025, at 09:38, Jakub Jelinek <[email protected]> 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.
Okay.
>
>> 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.
Okay.
>
>>> 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.
Currently, CLOBBER(bob) is defined as:
/* Beginning of object data, e.g. start of C++ constructor. This differs
from C++ 'lifetime', which starts when initialization is complete; a
clobber there would discard the initialization. */
CLOBBER_OBJECT_BEGIN,
Yeah, CLOBBER(bob) has the same effect of throwing away old content of the
object.
I have one question (might be a stupid question):
Should we consider a call to C++’s constructor as the initialization to that
variable?
For example:
S::S (&s);
Should we consider the above as an initialization to the variable s?
then -ftrivial-auto-var-init should NOT insert the DEFFRRED_INIT to s?
>
>> 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.
Okay, I see.
thanks.
Qing
>
> Jakub
