https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121894
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to qinzhao from comment #8)
> in tree-sra.cc, for the following stmt:
> s = {};
>
> for the above lhs "s", the field "grp_assignment_write" of the created
> struct access is 1;
>
> however, for the following stmt:
> s= .DEFERRED_INIT (8, 2, &"s"[0]);
>
> for the above lhs "s", the field "grp_assignment_write" of the created
> struct access is 0;
For SRA decisions, it is better to handle s = .DEFERRED_INIT (); similarly to
s = {};
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.
BTW, it might be also a good idea to CSE .DEFERRED_INIT calls with the same
arguments/same type with lhs SSA_NAME.
