similar to: Representing X86 long double in Debug Info

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

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

Looking into this more, what happens at the LLVM level is that we declare the size to be 80 bits and to find the storage size, we round up that size to the ABI alignment, so I could change the verifier check to do the same, which would solve the immediate issue for me. However, I would still like to figure out the DWARF question, esp. because it will be applicable to `i1`. On Mon, Nov 2, 2015 at

Adrian Prantl via llvm-dev wrote on Mon, 02 Nov 2015: > 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. The x86-64 and Darwin/i386 ABI define the size of the 80 bits extended

Hi All, I have question about 'isUnsignedDIType' function on 'llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp' When we want to generate object file with dwarf debug format, clang can generates 'DW_ATE_lo_user' encoding for complex integer type as follow: "clang/lib/CodeGen/CGDebugInfo.cpp" llvm::DIType *CGDebugInfo::CreateType(const ComplexType *Ty) { ... if

Unlike llvm itself, llvm-gcc needs to be configured for a particular target architecture. It looks like you're using a copy of llvm-gcc that was built to generate x86 code. On Sep 30, 2009, at 6:27 AM, Jin Gu Kang wrote: > Dear LLVM members. > > I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 > version. > > When i compiled 'od' program in

Dear LLVM members. I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 version. When i compiled 'od' program in coreutils package using LLVM 2.5, i could see the error message on llc processing. > llvm-gcc -emit-llvm ./od.c -c -o ./od.bc -other-options... > llc -march=arm ./od.bc -f -o ./od.s llc:

Hi Jin-Gu Kang! It are possible that the problem you are experiencing have already been solved in the current llvm 2.6 release tree and the current svn trunk. So try using llc from llvm 2.6 release branch or llvm pre2.7 svn trunk! It would be helpful if you could open a bugreport for this issue and attach the problematic od.bc since we need a testcase from the bitcode that exposes the bug inorder

Hi, I've been hacking around something missing in the assemble for the mingw-w64 targets the tfloat variable. I did some research into the llvm sources and did see x86_fp80 which seems to be the same thing. Can we support the .tfloat variable or the alternative ? Or is it under another name? I've tried using .x86_fp80 instead but to no avail. :/ Here is how tfloat is being used in

Hi Bob! I could not find llvm file for ARM target in llvm-gcc 4.2 front end source code. $llvm-gcc-src/gcc/config.gcc file alpha*-*-*) cpu_type=alpha need_64bit_hwint=yes # LLVM LOCAL begin out_cxx_file=alpha/llvm-alpha.cpp # LLVM LOCAL end ;; ... arm*-*-*) cpu_type=arm extra_headers="mmintrin.h" ;; ... i[34567]86-*-*) cpu_type=i386 # LLVM LOCAL begin

That is from 2.5, and just because there is nothing special listed in config.gcc does not mean it doesn't work. For 2.5, the ARM port of llvm-gcc did not require a separate llvm-arm.cpp source file, so nothing needed to be added to config.gcc. It worked fine as far as I know. For 2.6, you will see that there are some ARM-related changes to config.gcc in llvm-gcc. On Sep 30, 2009,

Hi, I am working on x86-64 and am working with a C frontend that folds sizeof(long double) into 12. For now, I am trying to avoid modifying that part of the frontend by finding a way to tell LLVM that 12 bytes are allocated for x86_fp80. To explore this, I tried an experiment with llvm-gcc: % llvm-gcc --version | head -1 llvm-gcc (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build

On Wed, Sep 23, 2009 at 2:27 PM, Talin <viridia at gmail.com> wrote: > On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: >> >> On Sep 22, 2009, at 4:49 PM, Talin wrote: >>> >>> // Calculate the size of the specified LLVM type. >>> Constant * DebugInfoBuilder::getSize(const Type * type) { >>>    Constant * one =

Hi, Can anyone help me understand that LLVM IR has "target independence" ? 1. When we talk about "target", we mean something like Instruction Set Architecture ? 2. The front-end may generate IR code such as x86_fp80, so the IR is actually not fully target-independent? It contains information about the target, and the front-end should also be aware of this? Thank you! Hao

This patch adds EmitTypeAuxAttribute() function to CGDebugInfo, which allows other parts of clang issue auxiliary information through an enumeration type in Dwarf information. For example, by calling DI->EmitTypeAuxAttribute(type, "ID", 1234); We can get following information in dwarf: <1><3f>: Abbrev Number: 3 (DW_TAG_structure_type) <40> DW_AT_name

Here is a patch that does just that. On Wed, Sep 23, 2009 at 3:38 PM, Devang Patel <devang.patel at gmail.com>wrote: > On Wed, Sep 23, 2009 at 2:27 PM, Talin <viridia at gmail.com> wrote: > > On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: > >> > >> On Sep 22, 2009, at 4:49 PM, Talin wrote: > >>> > >>>

Hi Mon Ping, > I would like to make it illegal to GEP into a vector as I think it is > cleaner and more consistent. Opinions? Comments? now that arrays are first class types, I think vectors should become a subclass of ArrayType. This would get rid of a lot of duplicated code, and also fix a bunch of problems with vectors (eg: that sizes are wrong; currently we think that a <n x

All, I should have chimed in earlier, but have been working on two more side-channel variants of this conversation. At the beginning the PNaCl team was strongly pushing for trying to keep platform ABI compatibility on all platforms while taking one portable bitcode stream as input. During the discussions we've had over the past few weeks it became obvious that that is simply not tractable,

Hi, Something like a sequential type makes sense especially in light of what Duncan is point out. I agree with Chris that a vector shouldn't be treated as a short array. Vectors have different alignment rules and operations. It make senses to talk about doing operations on vectors like add or speak of having a mask for a vector. I don't feel like that it make sense to talk of

I'm probably missing something simple here but in: CGDebugInfo.h: std::vector<std::pair<void *, llvm::WeakVH> >ReplaceMap; but then in CGDebugInfo.cpp: llvm::DIType TC = getTypeOrNull(Ty); void * v = Ty.getAsOpaquePtr(); std::pair<void *, llvm::WeakVH> tmp = std::make_pair(v, TC); if (TC.Verify() && TC.isForwardDecl())