> 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. > >> If all the auto variables are zero-initialized by the language standard, >> should -Wuninitialized still >> report warnings for uninitialized auto variables in the source code? > > Yes. The code using those is still erroneous, just won't trigger UB in that > case. > >> With the current patch, -Wunitialized still report warnings for >> uninitialized auto variables in the source code. >> Is this the expected behavior? > > Yes. Okay. Qing > > Jakub
