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.