Re: [PATCH] middle-end: Fix up C++26 P2795R5 - Erroneous behavior for uninitialized reads [PR126848]

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)