https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61595
--- Comment #4 from Sebastian Meyer <gcc-bugzilla at mailhell dot seb7.de> --- Richard: The typdef gets optimized away very quickly, so I needed to trick around a bit. But the array won't use the typedef anyway, the produced DWARF is equal to what was produced before (DWARF3 keeps it in debug_info, DWARF4 moves it to debug_types). Jakub: When addressing the array, computed address is <base address> + index * <element size>, the index does have no type (if I recall the C++ spec correctly). The DW_AT_type of the DW_TAG_subrange_type describes the actual content of each array element in the subrange. See Dwarf4 section 5.11 or Dwarf 3 section 5.12 (wording is the same): > The subrange entry may have a DW_AT_type attribute to describe the type of > object, called the > basis type, of whose values this subrange is a subset. > If the amount of storage allocated to hold each element of an object of the > given subrange type is > different from the amount of storage that is normally allocated to hold an > individual object of the > indicated element type, then the subrange type entry has a DW_AT_byte_size > attribute or > DW_AT_bit_size attribute, whose value (see Section 2.19) is the amount of > storage needed to > hold a value of the subrange type. As I said, I saw this with char arrays (DW_TAG_array_type.DW_AT_type = char), where each char was stored in a 4 byte int field (DW_TAG_subrange_type.DW_AT_type = int). The generated machine code did also iterate in steps of 4 bytes.
