From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4B7773858405; Thu, 10 Feb 2022 14:18:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4B7773858405 From: "jakub at gcc dot gnu.org" 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: Thu, 10 Feb 2022 14:18:02 +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: jakub at gcc dot gnu.org 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: attachments.created 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: Thu, 10 Feb 2022 14:18:03 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102586 --- Comment #9 from Jakub Jelinek --- Created attachment 52404 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D52404&action=3Dedit gcc12-pr102586.patch With this WIP patch which just ignores fields that partially overlap there = is no ICE and the (in the new testcase renamed) C5 case looks correct to me, __builtin_clear_padding there clears on x86_64 8 bytes at offsets 8 and 24 = into the 32-byte object, i.e. everything except for the 2 virtual table pointers. And the testcase verifies those virtual table pointers aren't cleared and so can be still dereferenced. But the C8 case which is derived from your smol case above looks weird. I'd expect (but need to look at the layout details yet) that the still 32-b= yte c8 object contains 2 virtual pointers and 1 byte c member and everything el= se is padding. But __builtin_clear_padding clears there 6 and 8 bytes instead= of 15 bytes together.=