> On Sep 6, 2025, at 10:10, Jason Merrill <ja...@redhat.com> wrote: > > On 9/4/25 10:42 PM, Qing Zhao wrote: >>> On Sep 4, 2025, at 16:15, Jakub Jelinek <ja...@redhat.com> wrote: >>> >>> On Thu, Sep 04, 2025 at 07:47:17PM +0000, Qing Zhao wrote: >>>>> On Sep 4, 2025, at 11:01, Jakub Jelinek <ja...@redhat.com> wrote: >>>>> >>>>> On Thu, Sep 04, 2025 at 02:45:16PM +0200, Jakub Jelinek via Gcc wrote: >>>>>> On Wed, Sep 03, 2025 at 03:38:53PM +0200, Jakub Jelinek via Gcc wrote: >>>>>>> But there is one thing the paper doesn't care about, which looks like a >>>>>>> show >>>>>>> stopper to me, in particular the stuff -Wtrivial-auto-var-init warning >>>>>>> warns >>>>>>> about. Consider: >>>>>> >>>>>> I've filed https://github.com/cplusplus/CWG/issues/758 for that. >>>>> >>>>> Here is an untested WIP. >>>>> >>>>> Regarding temporaries, I wonder if we want to .DEFERRED_INIT them when >>>>> expanding TARGET_EXPRs in the gimplifier (but whether to do that always >>>>> when flag_auto_var_init != AUTO_INIT_UNINITIALIZED or for C++26 only), >>>>> or if it should be in the C++ gimplification hook (but then it is more >>>>> costly because it would need to create a GENERIC IFN CALL only to >>>>> immediately gimplify it). >>>> >>>> I have the following questions regarding C++26: >>>> >>>> 1. Should all auto variables be zero-initialized by the compiler if they >>>> are not explicitly >>>> initialized in the source code per the language standard? >>> >>> Not necessarily. It should be initialized to some specific values, such >>> that e.g. two reads from it compare equal. Zero is the fastest IMHO, but >>> users should be able to use say -ftrivial-auto-var-init=pattern if they want >>> something else. And [[indeterminate]] variables don't have to be >>> initialized at all. >> A little confused here: >> In your patch, C++26 will automatically set flag_auto_var_init to the new >> AUTO_INIT_CXX26 even when -ftrivial-auto-var-init is not specified at all. >> Then flag_auto_var_init == AUTO_INIT_CXX26 will enable the insertion >> of .DEFFERED_INIT (size, AUTO_INIT_CXX26, ..) to the IR. >> So, for C++26, the compiler will always automatically add initialization >> for an >> uninitialized auto variable. Is this expected behavior? >> In your patch, there is no implementation of expanding .DEFFERED_INIT (size, >> AUTO_INIT_CXX26,…) >> yet, will this part be added later to initialize the variables to some >> specific values other than zero or pattern? >>>> 2. Should all temporaries be zero-initialized per the language standard? >>> >>> The same. And temporaries for direct function calls parameters which need >>> to be constructed (so aren't e.g. trivially copied from some other memory) >>> don't need to be initialized if it is a direct function call and the >>> parameter declarations are [[indeterminate]]. >> So, the temporaries will also be inserted a .DEFFERED_INIT (size, >> AUTO_INIT_CXX26,…), and then >> To be initialized to some specific values? >>> >>>> 3. Should the paddings of the auto variables or temporaries be >>>> zero-initialized per the standard? >>> >>> No. >> Okay. > > I disagree, I think the padding should also be initialized; the specification > says "the bytes comprising the storage for the object", not just the value > representation. > >> -ftrivial-auto-var-init currently is documented to initialize automatic >> variables to zero or pattern. Now, for c++26, when -ftrivial-auto-var-init >> is specified, in addition to uninitialized automatic >> variables in the source code, compiler generated temporaries (is this the >> correct understanding?) are also need to be initialized by .DEFFERED_INIT? >> My questions on this: >> 1. What kind of temporaries need to be initialized? > > TARGET_EXPR temporaries. Okay. > >> 2. What value will be used to initialized these temporaries? > > Presumably the same value as for automatic variables. Okay. > >> 3. Is this only for C++26? > > It seems appropriate to do this in general for -ftrivial-auto-var-init.
Then, should the end-user know this? Should we update the documentation to reflect this change? Qing > > Jason
