https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #27 from Qing Zhao <qing.zhao at oracle dot com> ---
> On Feb 11, 2022, at 11:47 AM, jakub at gcc dot gnu.org
> <gcc-bugzi...@gcc.gnu.org> wrote:
> But if I do:
> struct C { char a; int b; char c; long d; C () : a (42), b (42), c (42), d
> (42)
> {} };
> void bar (C *);
> void
> foo ()
> {
> C c;
> bar (&c);
> }
> then *.gimple is:
> c = .DEFERRED_INIT (24, 1, &"c"[0]);
> __builtin_clear_padding (&c, 0B, 1);
> C::C (&c);
> bar (&c);
> ...
> void C::C (struct C * const this)
> {
> *this = {CLOBBER};
> {
> this->a = 42;
> this->b = 42;
> this->c = 42;
> this->d = 42;
> }
> }
> After einline this is:
> c = .DEFERRED_INIT (24, 1, &"c"[0]);
> MEM <char[3]> [(struct C *)&c + 1B] = {};
> MEM <char[7]> [(struct C *)&c + 9B] = {};
> c ={v} {CLOBBER};
> c.a = 42;
> c.b = 42;
> c.c = 42;
> c.d = 42;
> bar (&c);
> and that keeps until dse1 which optimizes that out:
> c ={v} {CLOBBER};
> c.a = 42;
> c.b = 42;
> c.c = 42;
> c.d = 42;
> bar (&c);
> so there is no zero padding initialization at all.
Does this issue only exist with -flifetime-dse=2?
When -flifetime-dse=2, the call to __builtin_clear_padding should be inserted
AFTER the
start point of the constructor of the object, otherwise it’s dead and will be
eliminated by DSE.
And with -flifetime-dse=2, the padding initialization should be done by C++ FE
instead of middle end.
Is this understanding correct?
