https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117262
--- Comment #6 from David Malcolm <dmalcolm at gcc dot gnu.org> --- Looking at this again... (In reply to David Malcolm from comment #3) > I see: > > (gdb) pt ctor > <constructor 0x7fffea821390 > type <array_type 0x7fffea7f4930 > type <integer_type 0x7fffea664348 unsigned char sizes-gimplified > public unsigned QI > size <integer_cst 0x7fffea666048 constant 8> > unit-size <integer_cst 0x7fffea666060 constant 1> > align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type > 0x7fffea664348 precision:8 min <integer_cst 0x7fffea666078 0> max > <integer_cst 0x7fffea666018 255> > pointer_to_this <pointer_type 0x7fffea822540>> > BLK > size <integer_cst 0x7fffea7ea2d0 constant 576> > unit-size <integer_cst 0x7fffea7fff48 constant 72> > align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type > 0x7fffea7f4930 > domain <integer_type 0x7fffea7f4888 type <integer_type > 0x7fffea664000 sizetype> > sizes-gimplified DI > size <integer_cst 0x7fffea644f48 constant 64> > unit-size <integer_cst 0x7fffea644f60 constant 8> > align:64 warn_if_not_align:0 symtab:0 alias-set -1 > canonical-type 0x7fffea7f4888 precision:64 min <integer_cst 0x7fffea644f78 > 0> max <integer_cst 0x7fffea7fff30 71>>> > constant length:1 > idx <integer_cst 0x7fffea644fc0 type <integer_type 0x7fffea6640a8 > bitsizetype> constant 0> > val <raw_data_cst 0x7fffea7f3af0 type <integer_type 0x7fffea664348 > unsigned char> > constant>> I see the ctor node has a single pair with idx == integer_cst(0) val == raw_data_cst(72 bytes) binding_map::apply_ctor_to_region iterates through the (index, value) pairs via FOR_EACH_CONSTRUCTOR_ELT, and looks at the index of each: - if NULL_TREE, it treats the value as that of either a FIELD_DECL or the element given by the index of the iteration - if a RANGE_EXPR, it treats value as that for a range of element values - otherwise, it recurses (via apply_ctor_pair_to_child_region), and looks at INTEGER_CST as the element given by that value. So the code was expecting the idx of the CONSTRUCTOR_ELT to be RANGE_EXPR (0-71), rather than INTEGER_CST (0), and so the analyzer records that byte 0 of the array is initialized with the first byte of the raw_data_cst; if it had been given a RANGE_EXPR (0, 71) I believe it would have initialized bytes 0 - 71. Jakub: is this a bug in the tree the analyzer is being given, or should the analyzer handle an idx: integer_cst(x) val: raw_data_cst as a special-case meaning "initialize element[x] upwards through element [x + n - 1] with val"? (where n is the sizeeof raw_data_cst)
