search for: abstracttypeuser

...9;\\', HasValueHandle = 1 '\001', HasMetadata = 0 '\000', SubclassOptionalData = 31 '\037', SubclassData = 43368, VTy = {Ty = 0x921f6fc}, UseList = 0x8d5a550, Name = 0x8e06088} This is the output when I type "print *V1->getType()" in gdb: {<llvm::AbstractTypeUser> = {_vptr.AbstractTypeUser = 0x92184c0}, ID = 72, Abstract = true, SubclassData = 299242, RefCount = 153191633, Context = @0x89f3aac, ForwardType = 0x0, AbstractTypeUsers = {<std::_Vector_base<llvm::AbstractTypeUser*, std::allocator<llvm::AbstractTypeUser*> >> = { _M...

On Fri, 1 Sep 2006, Michael McCracken wrote: > Here's what works now, and I have a separate test case for each of these: > > statement functions > intrinsic functions (print, cos, etc) > loops, goto statments > scalarized array operations > function calls with *no arguments* > simple common blocks Great! > Function calls with more than one argument don't work.

Hi, when I try to compile an llvm program, it gives me the following error. Do you have idea on what I should look for? Thanks, Filippo llvm-as -f -o arith.bc arith.bc.exp llvm-as: Type.cpp:1034: void llvm::DerivedType::notifyUsesThatTypeBecameConcrete(): Assertion `AbstractTypeUsers.size() < OldSize-- && "AbstractTypeUser did not remove itself from the use list!"' failed. make: *** [arith.bc] Abortito

The NIST F77 test suite doesn't seem to be compatible with gfortran at all, so I had to work from my own sample codes, and generate test cases from them. Here's what works now, and I have a separate test case for each of these: statement functions intrinsic functions (print, cos, etc) loops, goto statments scalarized array operations function calls with *no arguments* simple common

...g directory `/usr/src/Lang/llvm/lib/Support' llvm[1]: Compiling APInt.cpp for Debug build In file included from /usr/src/Lang/llvm/include/llvm/Type.h:14, from /usr/src/Lang/llvm/include/llvm/DerivedTypes.h:21, from APInt.cpp:17: /usr/src/Lang/llvm/include/llvm/AbstractTypeUser.h:19:51: error: missing terminating ' character In file included from APInt.cpp:16: /usr/src/Lang/llvm/include/llvm/ADT/APInt.h:1041: warning: type qualifiers ignored on function return type /usr/src/Lang/llvm/include/llvm/ADT/APInt.h:1047: warning: type qualifiers ignored on function return ty...

Hi, We build a type with StructType::get(fModule->getContext(), fDspFields, false); with a fDspFields (std::vector<const llvm::Type*> fDspFields;) that is not yet completely known when we have to build the type. It is possible to add fields in a already build type? Thanks Stéphane Letz

On Jun 14, 2010, at 1:22 PM, Stéphane Letz wrote: > Hi, > > We build a type with StructType::get(fModule->getContext(), fDspFields, false); with a fDspFields (std::vector<const llvm::Type*> fDspFields;) that is not yet completely known when we have to build the type. It is possible to add fields in a already build type? Nope, types are immutable once created. The only

...#3 0x0000000000ba35e9 in llvm::PATypeHolder::addRef (this=0x1d7a740) at /home/maurice/installation/llvm-dev/include/llvm/Type.h:417 #4 0x0000000000dd872d in llvm::PATypeHolder::PATypeHolder(const struct llvm::Type *) (this=0x1d7a740, ty=0x0) at /home/maurice/installation/llvm-dev/include/llvm/AbstractTypeUser.h:143 #5 0x00000000015828d8 in llvm::DerivedType::dropAllTypeUses (this=0x1d777d0) at Type.cpp:469 #6 0x0000000001584b1f in llvm::DerivedType::unlockedRefineAbstractTypeTo (this=0x1d777d0, NewType=0x1d5b050) at Type.cpp:1454 #7 0x000000000158b84c in llvm::TypeMap<llvm::PointerValType, llvm::P...

On 25 June 2011 13:00, Duncan Sands <baldrick at free.fr> wrote: >> 3. Clang/dragonegg need to adapt to the new API (help appreciated!) > > what needs to be done exactly? Background info: http://www.nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt As I understand it, PATypeHolder, OpaqueType and the Module's TypeSymbolTable are gone. Instead, StructTypes can optionally be

...n llvm::PATypeHolder::get (this=0x8) at Type.cpp:46 46 const Type *NewTy = Ty->getForwardedType(); (gdb) bt #0 0x0861bf59 in llvm::PATypeHolder::get (this=0x8) at Type.cpp:46 #1 0x0837cac5 in llvm::PATypeHolder::operator llvm::Type* (this=0x8) at /work/aditya/llvm-2.2/include/llvm/AbstractTypeUser.h:149 #2 0x0837cadc in llvm::Value::getType (this=0x0) at /work/aditya/llvm-2.2/include/llvm/Value.h:87 #3 0x08637b52 in (anonymous namespace)::Verifier::visitBinaryOperator (this=0x8794f18, B=@0x87994a8) at Verifier.cpp:905 #4 0x0863d81e in llvm::InstVisitor<(anonymous namespace)::Ve...

Hi Chris, > 3. Clang/dragonegg need to adapt to the new API (help appreciated!) what needs to be done exactly? Ciao, Duncan.

On Thu, 3 May 2007, Basile STARYNKEVITCH wrote: > > What version of g++ is usable to compile the latest LLVM CVS snapshot on a > Linux/x86-64 (AMD64) Debian/ Sid or Etch plateform? Please look here: http://llvm.org/docs/GettingStarted.html#brokengcc I'd suggest late versions of GCC 4.0.x. The 4.1 series has had numerous problems compiling LLVM on x86-64, though some people have

Hello All, What version of g++ is usable to compile the latest LLVM CVS snapshot on a Linux/x86-64 (AMD64) Debian/ Sid or Etch plateform? What compiler do LLVM dzevelopers use to compile LLVM on Linux/X86-64 systems? IKt seems that most versions of g++ fail to compile LLVM and that some others compile it wrongly (producing buggy code)? Why can't g++-4.1 be used? FWIW, the latest gcc

...aarumgxp /cygdrive/c/llvm-2.8/include $ ls llvm/ llvm-c/ aarumug at aarumgxp /cygdrive/c/llvm-2.8/include $ cd llvm aarumug at aarumgxp /cygdrive/c/llvm-2.8/include/llvm $ ls ADT/ CallingConv.h GlobalValue.h IntrinsicsARM.td Metadata.h SymbolTableListTraits.h AbstractTypeUser.h CodeGen/ GlobalVariable.h IntrinsicsAlpha.td Module.h System/ Analysis/ CompilerDriver/ InlineAsm.h IntrinsicsCellSPU.td OperandTraits.h Target/ Argument.h Config/ InstrTypes.h IntrinsicsPowerPC.td Operator.h Transform...

Hello, I have a couple of doubts, as listed below: 1. To list all the global variables in the module, I am iterating using type_iterator and for each Type I get, I am using value_iterator to iterate over Values . In the second iteration I am getting unexpected results. For each type obtained from type_iterator->second, value_iterator->first produces the same list as what

...ctTypes can optionally be > named, and if they are then: > > - they use name equivalence instead of structural equivalence. > - you can create them without any fields, and then add the fields > later when the struct is complete. Right, exactly. The major impact is that the various AbstractTypeUser-related classes (including OpaqueType) are gone, and the StructType interface is richer: http://llvm.org/viewvc/llvm-project/llvm/branches/type-system-rewrite/include/llvm/DerivedTypes.h?revision=133420&view=markup > I've played with the Clang bits of this. The biggest problem I've...

Hi, Here is the follow on patch for this problem. Please apply this from the top of the tree and rebuild. -------------- next part -------------- A non-text attachment was scrubbed... Name: op Type: application/octet-stream Size: 2548 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060315/eee8a766/attachment.obj> -------------- next part

I found 179 more *.{c,cpp,h} files with tabs. Unfortunately, the tabs stops used vary so blindly expanding them messes up alignment in many cases :( Index: examples/BFtoLLVM/BFtoLLVM.cpp Index: include/llvm/AbstractTypeUser.h Index: include/llvm/GlobalVariable.h Index: include/llvm/InstrTypes.h Index: include/llvm/IntrinsicInst.h Index: include/llvm/ADT/PostOrderIterator.h Index: include/llvm/Analysis/ConstantsScanner.h Index: include/llvm/Analysis/IntervalIterator.h Index: include/llvm/Analysis/Verifier.h Index: incl...

...erious: Program received signal SIGSEGV, Segmentation fault. llvm::PATypeHolder::get (this=0x8) at Type.h:249 249 const Type *getForwardedType() const { (gdb) where #0 llvm::PATypeHolder::get (this=0x8) at Type.h:249 #1 0x08514f1f in llvm::PATypeHolder::operator llvm::Type* (this=0x8) at AbstractTypeUser.h:140 #2 0x08514734 in llvm::Value::getType (this=0x0) at Value.h:76 #3 0x087a8f8a in ConstantStruct (this=0x8b28038, T=0x8b25730, V=@0xbf8adef0) at /home/ghost/Work/llvm-cvs/lib/VMCore/Constants.cpp:275 #4 0x087e9058 in llvm::ConstantCreator<llvm::ConstantStruct, llvm::StructType, std::v...

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached