On Tue, 18 Aug 2026, Jakub Jelinek wrote: > On Tue, Aug 18, 2026 at 10:24:06AM +0200, Richard Biener wrote: > > Hmm. As it now makes semantic difference, can we instead put the > > flag_auto_var_init mode in the .DEFERRED_INIT call as argument? > > It is already there and the patch makes use of it. > The first argument of .DEFERRED_INIT is the size, the second > is the flag_auto_var_init value and the third one some string > literal description.
Oh, I mis-spotted flag_auto_var_init uses. > > Because we do not seem to prohibit inlining between functions > > with different flag_auto_var_init modes (not sure if that would be > > a problem already), see can_inline_edge_by_limits_p. > > > > Also for optimization purposes, wouldn't a 'zero' be a better > > "same" value than treating this as VARYING? > > For -std=c++26 -ftrivial-auto-var-init=pattern that would be incorrect, > because the value in that case is some non-zero constant, and otherwise > I'd be just afraid it would prevent many -Wuninitialized warnings. > After last uninit pass perhaps we could fold the scalar AUTO_INIT_CXX26 > or AUTO_INIT_ZERO | AUTO_INIT_CXX26 to zero, sure (currently only done > in RTL optimizations). I see. The patch is OK from my side, but leave Jason the chance to comment on the c-family parts and testsuite. Thanks, Richard. > > Jakub > > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Jochen Jaser, Andrew McDonald, Abhinav Puri; (HRB 36809, AG Nuernberg)
