search for: dw_at_bit_size

That was essentially part of my question. The DWARF standard says: If the value of an object of the given type does not fully occupy the > storage described by a byte size attribute, the base type entry may also > have a DW_AT_bit_size and a DW_AT_data_bit_offset attribute, both of whose > values are integer constant values (see Section 2.19). The bit size > attribute describes the actual size in bits used to represent values of the > given type. The data bit offset attribute is the offset in bits from the > beginning...

...F is fairly flexible & >> doesn't dictate "right" answers, as such. >> >> This time, actually the "right" answer is fairly clear (and in normative >> text, no less) right there in section 5.1. Use DW_AT_byte_size for the >> storage size and DW_AT_bit_size for the value size. >> > > I'm not sure - it seems like a valid interpretation to believe that the > value is 128 bits - some of those bits are always zero. (& of course the > DWARF spec says "the base type entry /may/ also have", because it's all > permis...

...We might have to special case this in the verifier, but before we do that, I wanted to ask about the following: Reading the DWARF standard, it seems like the following would be a valid description of an X86 80bit long double: DW_TAG_base_type DW_AT_name "long double" DW_AT_byte_size 16 DW_AT_bit_size 80 As far as I can tell from looking through the source code, both LLDB and GDB would read this just fine, it would be a more accurate description of a long double and if we add support for it in LLVM IR, the verifier would be able to understand what's actually going on. Does this seem li...

On Mon, Nov 2, 2015 at 8:38 AM, Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Looking at the code in clang CGDebugInfo just passes through the width of > the type as it is described by the TypeInfo, which in turn is defined by > the Target. At the moment I do not understand why an x86_fp80 is reported > to be 128 bits wide. (Since it’s a type natively