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.
> 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).
Jakub
