https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121894
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #9)
>
> For SRA decisions, it is better to handle s = .DEFERRED_INIT (); similarly to
> s = {};
Yes, that's what I am doing right now: try to fix this first.
> after all, except for -ftrivial-auto-var-init=pattern it actually expands
> that way later on and for pattern, while it doesn't zero initialize, it
> initializes everything to something else, as if it was
> s {v} = {CLOBBER};
> s.a = 0xfefefefe;
> s.b = 0xfefefefe;
> s.c = 0xfefefefe;
> s.d = 0xfefefefe;
> Except for -Wuninitialized purposes we obviously do want to keep the
> .DEFERRED_INIT calls rather than folding it to 0 or 0xfe initialization
> right away.
could you clarify a little bit here? right now, we keep the call to
.DEFERRRED_INIT till "expand" phase. are you suggesting to keep the call to
.DEFERRED_INIT even later?
> BTW, it might be also a good idea to CSE .DEFERRED_INIT calls with the same
> arguments/same type with lhs SSA_NAME.
yeah, good idea
