From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 4B6FB3858D1E; Wed,  9 Feb 2022 17:21:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4B6FB3858D1E
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.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: Wed, 09 Feb 2022 17:21:03 +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: jason 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: 
Message-ID: <bug-102586-4-8xPRHBcDSf@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102586-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102586-4@http.gcc.gnu.org/bugzilla/>
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 <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Feb 2022 17:21:03 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102586

--- Comment #7 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> Shall it treat the fields that partially fall into the range and partially
> don't as padding (ignore them)

In short yes, but...

What a wacky class hierarchy.

So, when laying out C5, we first choose C2 as its primary base class; C4 is=
 not
eligible because its direct C1 base is at offset 8 (in C4) to avoid conflic=
ting
with C2's C1.

So then C5's C1 direct base is also at offset 8 to avoid C2's C1.

Then we place the C4 virtual base, which can also go at offset 8, because i=
ts
C1 will end up at offset 16 in C5.

But the C5 base of C9 doesn't include the C4 vbase, so when we look at C4 v=
base
we see that it overlaps the end and yes, we can safely ignore it.

It would be possible to make a hierarchy where a one-byte vbase shares the
padding byte with C1:

struct smol { char c; };
struct C5 : virtual smol, virtual C4, C1 {};

Now smol and C1 are both one byte at offset 8, so we only know to ignore sm=
ol
if we know whether we're supposed to look at vbases or not.  So we might
wrongly treat that byte as data in C9 when it's actually padding.

I'd think it should be possible to handle this without a langhook by lookin=
g at
the BINFOs at the same time, i.e. within a base field, ignore BINFO_VIRTUAL=
_P
with non-0 offset.=