similar to: [LLVMdev] Strange error using CallInst constructor

Please keep replies on the list. Now you've missed "InputIterator must be a random-access iterator pointing to contiguous storage (e.g. a std::vector<>::iterator). Checks are made for random-accessness but not for contiguous storage as that would incur runtime overhead." from CallInst's constructor (although that comment should be on Create()). Function::arg_iterator

On Monday 02 July 2007 23:24, David A. Greene wrote: > > > - Changing the API > > > a) Template it to take two iterators. This causes code size bloat. > > This seems like the right solution to me. Unless llvm is running on > extremely limited memory embedded systems, the extra code space > shouldn't be an issue. It turns out this wasn't quite a simple as

Hi, I'm trying to add function calls in the LLVM IR using the IRBuilder class. I've read both tutorials about functions but I still get assertion errors. I allocate memory for all function arguments and pass them as explained in the tutorial. My code is (this function is supposed to add a call to f in bb at pos): void addCallSite(Function *f, BasicBlock *bb, BasicBlock::iterator pos)

On Wed, 4 Jul 2007, David A. Greene wrote: > On Monday 02 July 2007 23:24, David A. Greene wrote: >>>> - Changing the API >>>> a) Template it to take two iterators. This causes code size bloat. >> >> This seems like the right solution to me. Unless llvm is running on >> extremely limited memory embedded systems, the extra code space >>

On Monday 02 July 2007 16:26, Chris Lattner wrote: > On Sun, 1 Jul 2007, Nick Lewycky wrote: > > I've been running LLVM with _GLIBCXX_DEBUG (extra checks) turned on to > > see what would happen, and it's been a complete disaster. Well, that's a bit harsh, isn't it? It's finding bugs, just like it's supposed to. :) I believe I've started to run into

CreateAlloca(Type) returns an object of type Type*, the memory that can hold an object of type Type. You probably don't want to be creating allocas just before calling the function since 1) if that call winds up in a loop they'll grow your stack frame without bound, and 2) the memory they point to is initially uninitialized. Where did the tutorial tell you to do that? In general, when I

On Wednesday 04 July 2007 14:57, Chris Lattner wrote: > > template<typename InputIterator> > > CallInst(Value *Func, InputIterator ArgBegin, InputIterator ArgEnd, > > const std::string &Name = "", Instruction *InsertBefore = 0, > > Is it acceptable to just make the template argument be the container? > That way you could pass: > >

Hi, Thanks both of you for the help. I just missed that Create function had many optional arguments... sorry for that. However my problem wasn't coming from here (IRBuilder CreateCall function still return a pointer to CallInst so I just added 2 times the call?). I didn't wanted to detail the all issue previously because I knew I had a problem with my syntax. So here's my problem: I

Hi Josef, > Okay, I've done a lot more testing and I now have a .bc file that compiles for x86, sparc, mips but refuses to compile for the mblaze and powerPC backends because of the calling convention. Is there anyone that would know how to fix the microblaze calling convention or point me in the right direction on how to fix it? what does "refuses to compile" mean? I.e. what

> what does "refuses to compile" mean? I.e. what error do you get? > Specifically I get this message when compiling with the default -mattr: Call result #2 has unhandled type i32 UNREACHABLE executed at CallingConvLower.cpp:162! 0 llc 0x0000000100a1e115 PrintStackTrace(void*) + 38 1 llc 0x0000000100a1e6d0 SignalHandler(int) + 254 2

Hi everyone, I am trying to replace the call of a certain function with a call to another function. It would for example replace the following: %call = tail call noalias i8* @func(i64 10) by %call = tail call noalias i8* @other_func(i64 10) I managed to declare other_func correctly but I am having troubles to understand how I should proceed to do the replacement. I tried to use

Here's a sketch of what I am proposing for ConstantBuilder. I'd like feedback on naming conventions, doc comments, etc. //===-- llvm/Support/ConstantBuilder.h - Builder for Constants --*- C++ -*-===// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. //

Dear colleagues, I'm looking if we can replace nvopencc with LLVM NVPTX in our project. It turns NVPTX won't work with the code nvopencc can handle (please see the log below). So are atomic intrinsics not supported or am I doing call in a wrong way? Thanks, - Dima. SOURCE ======== dmikushin at hp2:~> cat kernelgen_monitor.ll ; ModuleID =

Devang Patel wrote: > On Dec 15, 2007, at 12:15 PM, Richard Pennington wrote: > >> I got the current version of LLVM via svn yesterday and modified my >> code to >> use the LLVMFoldingBuilder. Very nice! >> >> My question is this: I noticed that the folding builder doesn't fold >> some >> operations, e.g. casts. Is there some reason why? If

I used &Idx[0]. In future, please avoid tabs in your patch. I applied your patch. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071217/056403.html - Devang On Dec 17, 2007, at 2:57 AM, Richard Pennington wrote: > Devang Patel wrote: >> On Dec 15, 2007, at 12:15 PM, Richard Pennington wrote: >>> I got the current version of LLVM via svn yesterday and

On Jul 22, 2008, at 11:54 PM, Matthijs Kooijman wrote: > Hi Chris, > > >> I'd prefer to not turn this into a template. Why not just define a >> version that takes an array of uint64_t's or something like that? > because I want to be able to pass in iterators. I could define a > version that > takes std<uint64_t>::iterators, but next thing we know, we

Hello, Recently I've introduced a feature in Clang to parse documentation comments and emit warnings for misuse of Doxygen commands in comments. It would be good to have LLVM and Clang build cleanly with -Wdocumentation. There are only a few warnings left. Please help with the part of the code you are familiar with. After we have zero warnings, we will enable -Wdocumentation by default.

I made the llvm::Function() constructor public (for testing purpose) and used the non-overloaded new. auto func = ::new llvm::Function(...) if (func) func->eraseFromParent(); And the heap corruption is gone! Did something changed in llvm::User::new between 3.7.1 and 3.8.0 ? I found a bug in llvm ? On Thu, Feb 25, 2016 at 12:10 PM, koffie drinker <gekkekoe at gmail.com> wrote: > I

I found the root cause, but I don't know what's the best approach to fix it. Under windows, 64 bit, when a function is created the void *User::operator new(size_t Size) operator allocates space + Use*. In the Use* the HasHungOffUses is set to true. So the ptr to the use* is returned as new object. This ptr is NOT the ptr that was allocated by the system. For that ptr you need ptr - word

Turns out llvm initializes memory before the constructor is invoked. Visual studio has /sdl by default on, and the __autoclassinit2 will zero the memory before the constructor is reached causing all the setters to be default zero. which clears the hashungoff var and causing the delete to flow in wrong part. When /sdl is enabled, the compiler generates code to perform these checks at run time: —