> On Sep 3, 2025, at 12:32, Jakub Jelinek <ja...@redhat.com> wrote:
> 
> 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.
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


Reply via email to