From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 254D9385841B; Fri, 11 Feb 2022 21:52:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 254D9385841B From: "qing.zhao at oracle dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a Date: Fri, 11 Feb 2022 21:52:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: qing.zhao at oracle dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2022 21:52:06 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102586 --- Comment #27 from Qing Zhao --- > On Feb 11, 2022, at 11:47 AM, jakub at gcc dot 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 =3D .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 =3D {CLOBBER}; > { > this->a =3D 42; > this->b =3D 42; > this->c =3D 42; > this->d =3D 42; > } > } > After einline this is: > c =3D .DEFERRED_INIT (24, 1, &"c"[0]); > MEM [(struct C *)&c + 1B] =3D {}; > MEM [(struct C *)&c + 9B] =3D {}; > c =3D{v} {CLOBBER}; > c.a =3D 42; > c.b =3D 42; > c.c =3D 42; > c.d =3D 42; > bar (&c); > and that keeps until dse1 which optimizes that out: > c =3D{v} {CLOBBER}; > c.a =3D 42; > c.b =3D 42; > c.c =3D 42; > c.d =3D 42; > bar (&c); > so there is no zero padding initialization at all. Does this issue only exist with -flifetime-dse=3D2? When -flifetime-dse=3D2, the call to __builtin_clear_padding should be inse= rted AFTER the start point of the constructor of the object, otherwise it=E2=80=99s dead a= nd will be eliminated by DSE.=20 And with -flifetime-dse=3D2, the padding initialization should be done by C= ++ FE instead of middle end. Is this understanding correct?=