[Bug debug/61595] New: Inconsistent DWARF information for arrays of vector types

[Bug debug/61595] New: Inconsistent DWARF information for arrays of vector types

[gcc-bugzilla at mailhell dot seb7.de]

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

            Bug ID: 61595
           Summary: Inconsistent DWARF information for arrays of vector
                    types
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc-bugzilla at mailhell dot seb7.de

While writing a DWARF parser/interpreter I hit what seems to be inconsistent
DWARF information.
The original source for my example originates from
"libgcc/config/rs6000/linux-unwind.h" of some older gcc-4.1.0 for powerpc, but
I reproduced the issue for the version on my workstation, which is "g++ (SUSE
Linux) 4.7.2 20130108 [gcc-4_7-branch revision 195012]" on x86_64.

Minimal example c++ code:
> struct gcc_vregs
> {
>   __attribute__ ((vector_size (16))) int vr[32];
> };
> 
> typedef int v4si __attribute__ ((vector_size (16)));
> 
> int main (int argc, char** argv) {
>     gcc_vregs testData;
>     for (int i = 0; i < 32; i++) {
>         v4si x = {i,i+32,i+64,i+96};
>         testData.vr[i] = x;
>     }   
> 
>     return 0;
> }

I compiled using "g++ minimal.c -gdwarf-4 -O0 -o minimal" and produced a DWARF
output with "objdump minimal -g > minimal.S".
The interesting snippet there is the type of gcc_vregs:
>  <1><25>: Abbrev Number: 2 (DW_TAG_structure_type)
>     <26>   DW_AT_name        : (indirect string, offset: 0xd7): gcc_vregs 
>     <2a>   DW_AT_byte_size   : 512
>     <2c>   DW_AT_decl_file   : 1  
>     <2d>   DW_AT_decl_line   : 1  
>     <2e>   DW_AT_sibling     : <0x3e> 
>  <2><32>: Abbrev Number: 3 (DW_TAG_member)
>     <33>   DW_AT_name        : vr 
>     <36>   DW_AT_decl_file   : 1  
>     <37>   DW_AT_decl_line   : 3  
>     <38>   DW_AT_type        : <0x3e> 
>     <3c>   DW_AT_data_member_location: 0  
>  <1><3e>: Abbrev Number: 4 (DW_TAG_array_type)
>     <3f>   DW_AT_type        : <0x4e> 
>     <43>   DW_AT_sibling     : <0x4e> 
>  <2><47>: Abbrev Number: 5 (DW_TAG_subrange_type)
>     <48>   DW_AT_type        : <0x5a> 
>     <4c>   DW_AT_upper_bound : 31 
>  <1><4e>: Abbrev Number: 6 (DW_TAG_array_type)
>     <4f>   DW_AT_GNU_vector  : 1  
>     <4f>   DW_AT_type        : <0x61> 
>     <53>   DW_AT_sibling     : <0x5a> 
>  <2><57>: Abbrev Number: 7 (DW_TAG_subrange_type)
>     <58>   DW_AT_upper_bound : 3  
>  <1><5a>: Abbrev Number: 8 (DW_TAG_base_type)
>     <5b>   DW_AT_byte_size   : 8  
>     <5c>   DW_AT_encoding    : 7  (unsigned)
>     <5d>   DW_AT_name        : (indirect string, offset: 0x80): sizetype  
>  <1><61>: Abbrev Number: 9 (DW_TAG_base_type)
>     <62>   DW_AT_byte_size   : 4  
>     <63>   DW_AT_encoding    : 5  (signed)
>     <64>   DW_AT_name        : int

As you can see, the total size of gcc_vregs is 512 bytes.
Running the code in gdb and examining main memory prior to the return statement
verifies that the variable testData contains 128 values, each being a 4 byte
integer (see testData.txt in the appended tar for a hexdump of its memory
region).

The DW_AT_type of its member vr is 0x4e, which is an array (or, in fact, a
vector) containing four sizetype's of size 8 bytes each.
So in total a child of vr is 4*8 = 32 bytes large.
Using this information, the total size is <array element count> * 32 bytes.
Since there is just one subrange of size 32, the element count is 32 and thus
the total size should be 1024 bytes.

On the other hand, the 32 element subrange of vr has the type 0x5a.
This is the 'sizetype' of size 8 bytes. So each of the subrange elements should
be 8 bytes small, and the computed size of the array vr (ignoring its own
DW_AT_type) is 8 bytes * 32 = 256.

As you can see, both ways compute a different size.
While it is possible they differ, usually a small DW_TAG_array_types'
DW_AT_type is stored in a bigger DW_TAG_subrange_type's DW_AT_type.
I.e. a 'unsigned char[16]' could store each char (of size 1) in an unsigned int
(of size 4) due to alignment restrictions.

But the code generated here is completely off, since the size is definitely 512
bytes (32 Elements in the array, each element is vector of four 4 byte ints ->
32 * 4 * 4 Bytes = 512 Bytes; verified against binaries behaviour).

Expected:
* The DW_TAG_base_type at 0x5a should be unsigned int with a DW_AT_byte_size of
4.
* The DW_TAG_subrange_type at 0x47 should be of type 0x4e -> it's a subrange
containing 32 elements, which are themselfs vectors of four 4 byte integer
values.

I append a tarball containing
* minimal.c - my minimal example source code
* minimal.S - DWARF information
* testData.txt - a memory dump of the variable 'testData' prior to the return.

I don't know about the policy for binaries, so I didn't attach it. But I can
still do so, if that is required.

[Bug debug/61595] Inconsistent DWARF information for arrays of vector types

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, does it work if you do

typedef int vint __attribute__((vector_size(16)));

and use vint in as the type for vr?

[Bug debug/61595] Inconsistent DWARF information for arrays of vector types

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I don't see anything wrong on the emitted DWARF.  DW_AT_type on
DW_TAG_subrange_type is the type of the array indexes, not the array elements.
The type of the array elements is DW_AT_type on DW_TAG_array_type.

[Bug debug/61595] Inconsistent DWARF information for arrays of vector types

[gcc-bugzilla at mailhell dot seb7.de]

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.

[Bug debug/61595] Inconsistent DWARF information for arrays of vector types

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
You are clearly misreading what the standard says.
DW_AT_type on DW_TAG_subrange_type is the basis type of the subrange.
Say if you have array char a[5];, then the subrange of the array is 0:5 and the
type of the subrange is the type of the 0 and 5 constants - the lower/upper
bounds.
If you continue reading 5.11, you'll see that if DW_AT_type is missing on the
subrange, then it defaults to the type of DW_AT_lower_bound object, or
DW_AT_upper_bound object (if they are object), or integer with the size of
address.  Nothing related to the element type, the subrange is not about
elements, but extents of the array.

[Bug debug/61595] Inconsistent DWARF information for arrays of vector types

[gcc-bugzilla at mailhell dot seb7.de]

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

--- Comment #6 from Sebastian Meyer <gcc-bugzilla at mailhell dot seb7.de> ---
Ah, okay, thank you for the clarification, Jakub.
So this is indeed RESOLVED INVALID, sorry.

I am still sure I saw the example I gave, but can't seem to find it now.
Chances are good though it wasn't GCC, since (after implementing functionality
for a new tag) I usually look at GCC binaries first before I examine other
compilers and I remember rewriting the array/subrange interpretation part.
If the binary happens to cross my way again (must be part of our test suites) I
will post some details on that.