[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a

["jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- 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 conflicting
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 its
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 vbase
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 smol
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 looking at
the BINFOs at the same time, i.e. within a base field, ignore BINFO_VIRTUAL_P
with non-0 offset.