[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 15 Feb 2023, qinzhao at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
> 
> --- Comment #6 from qinzhao at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #2)
> > 
> > The gimplifier instead of
> > 
> >       _1 = t ();
> >       D.2389 = _1;
> >       e = &D.2389;
> >       _2 = *e;
> >       f (_2);
> > 
> > produces
> > 
> >       _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
> >       D.2389 = _1;
> >       e = .DEFERRED_INIT (8, 2, &"e"[0]);
> >       _2 = t ();
> >       D.2389 = _2;
> >       e = &D.2389;
> >       _3 = *e;
> >       f (_3);
> > 
> > which is odd and sub-optimal at least.  Doing such things makes us rely
> > on DSE to elide the uninit "inits".
> 
> actually, this is because, The simplifier sees the following  IR from FE
> (.original)
> 
>     const int D.2768;
>     const int & e;
>   <<cleanup_point <<< Unknown tree: expr_stmt
>     (void) (e = D.2768 = t ();, (const int &) &D.2768;) >>>>>;
>   <<cleanup_point <<< Unknown tree: expr_stmt
>     f ((int) *e) >>>>>;
> }
> 
> i.e, it sees two DECL_EXPR "D.2768" and "e" without any initialization first,
> and then see the "CLEANUP_POINT_EXPR" which include the initializations to "e"
> and "D.2768". since it doesn't see any connections between these two DECL_EXPRs
> and the initializations inside "CLEANUP_POINT_EXPR", it just treats the two
> DECL_EXPRs as not initialized, therefore add the .DEFERED_INIT to them.
> 
> the best approach to resolve this issue is:
> 
> if there is any connection  between DECL_EXPR "D.2768","e" and their
> initializations inside "CLEANUP_POINT_EXPR" that can be checked from IR, then
> during "gimplify_decl_expr", we can avoid generating .DEFERRED_INIT to them;
> 
> my question is: in the current IR from C++ FE, is there any bit I can check to
> make sure that the DECL_EXPR "D.2768" and "e" already have initialization
> inside "CLEANUP_POINT_EXPR"?

Hmm, I don't think so.  So this is indeed expected behavior since the
frontend IL doesn't have variable definitions with initializers but
instead just (immediately following) assignments.