https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Which binfo has non-0 offset though?
When processing that C5 type with sz of 9, the FIELD_DECLs have C2 type and
debug_tree (field)
<field_decl 0x7fffea3bdda8 D.2410
type <record_type 0x7fffea3a8348 C2 addressable needs-constructing
cxx-odr-p type_5 BLK
size <integer_cst 0x7fffea23ef48 constant 64>
unit-size <integer_cst 0x7fffea23ef60 constant 8>
...
private ignored decl_6 BLK pr102586.C:5:8 size <integer_cst 0x7fffea23ef48
64> unit-size <integer_cst 0x7fffea23ef60 8>
...
and
p debug_tree (field->typed.type->type_non_common.maxval)
<tree_binfo 0x7fffea3bc000
type <record_type 0x7fffea3a8348 C2 addressable needs-constructing
cxx-odr-p type_5 BLK
...
tree_2 bases:2 offset <integer_cst 0x7fffea23ef78 0>>
then there is a FIELD_DECL with C1 type which is ignored because it is an empty
type and then
p debug_tree (field)
<field_decl 0x7fffea3c4130 D.2415
type <record_type 0x7fffea3bf348 C4 addressable needs-constructing
cxx-odr-p type_5 BLK
size <integer_cst 0x7fffea23ef90 constant 128>
unit-size <integer_cst 0x7fffea23efa8 constant 16>
...
size <integer_cst 0x7fffea3b5ca8 type <integer_type 0x7fffea25f0a8
bitsizetype> constant 72>
unit-size <integer_cst 0x7fffea3b5c78 type <integer_type 0x7fffea25f000
sizetype> constant 9>
...
p debug_tree (field->typed.type->type_non_common.maxval)
<tree_binfo 0x7fffea3bc070
type <record_type 0x7fffea3bf348 C4 addressable needs-constructing
cxx-odr-p type_5 BLK
...
tree_2 bases:2 offset <integer_cst 0x7fffea23ef78 0>>
so TYPE_BINFO (TREE_TYPE (field)) is non-NULL and
BINFO_OFFSET (TYPE_BINFO (TREE_TYPE (field))) is integer_zerop in both cases.
