search for: abstracttypeusers

...= 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_impl = {<std::allocator<llvm::AbstractTypeUser*>> = {<__gnu_cxx::new_allocator<llvm::AbstractTypeUser*>> = {<No data fields>}, <No data field...

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

Le Thu, May 03, 2007 at 09:36:22AM -0700, Chris Lattner écrivait/wrote: > On Thu, 3 May 2007, Basile STARYNKEVITCH wrote: > > > > > FWIW, the latest gcc snapshot from yesterday gcc version 4.3.0 20070501 > > (experimental) fail to compile latest LLVM (with compile errors!). > > Please file an llvm bug report with these errors. It may be that we are > doing

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

Hi, I am using current SVN and in the last week or so, something causing the following assertion failure has changed. void llvm::PATypeHolder::addRef(): Assertion `Ty && "Type Holder has a null type!"' failed. The corresponding stack trace is: #0 0x000000339ec332f5 in raise () from /lib64/libc.so.6 #1 0x000000339ec34b20 in abort () from /lib64/libc.so.6 #2

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

Hi, I tried creating intrinsics which are to be placeholders for a set of instructions which should not be executed by the backend. I get the following verifier error. The "indvar.next4" instruction being mentioned in the step wise debug is not present in the LLVM IR (i.e IR before application of my transformation Pass). As seen below the operands of this instructions causing

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

Hi, I followed the build instructions at http://www.aarongray.org/LLVM/BuildingLLVMonCygwin.html to build LLVM and LLVM GCC. Everything went fine except for the 'make install' step of llvm. At this step, I am getting a big list of files which are under /cygdrive/c/llvm-2.8/include/llvm and /cygdrive/c/llvm-2.8/include/llvm-c. The error I am getting is: /usr/bin/install:

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

On Jun 25, 2011, at 11:59 AM, Jay Foad wrote: > 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

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:

Evan Cheng wrote: > Hi, > > Here is the follow on patch for this problem. Please apply this from > the top of the tree and rebuild. With the patch from Chris and then the patch from you combined, the previous error disappeared, but I get another error, reduced to this: ./cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mtune=pentiumpro -auxbase-strip libgcc/./_clz.o -g -O2

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