search for: byte_size

...e offset are padding. which made me think the representation I proposed in the original email might be correct (i.e. an 80bit value, but always stores as 16 bytes). As far as I see it, there's 3 questions here: 1) What's the right representation in DWARF? 2) If we think it should be the byte_size/bit_size combination, how do we describe this in IR, because right now, even though the size is in bits, will always emit `DW_AT_byte_size $(size>>3)` 3) How would clang describe this in it's TargetInfo Just to throw my opinion out there: 1) Use the DW_AT_bit_size/DW_AT_byte_size 2) Add...

...nfortunately impossible/hard to answer. DWARF 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/...

Hi all, I was wondering about the class used when rails receives file uploads. Sometimes it appears to be a File, and other times it is a StringIO. Also it has methods such as original_filename that don''t appear to belong to either of these classes. I ask because I''m trying to work out how to test my fil upload related models and controllers. Is there some standardised way of

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

...e debug info. 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...