similar to: [LLVMdev] Changes in FunctionPassManager constructor

Hi Christophe, So this is a pain, but we are dealing with a pre-release. Until the 2.7 freeze the source should continue to churn. Regards Garrison On Feb 3, 2010, at 11:34, Christophe de Dinechin wrote: > What guarantees does LLVM try to provide regarding source code compatibility? > > Case in point: rev 94686 (http://llvm.org/viewvc/llvm-project?view=rev&revision=94686) breaks

So, it looks like I mis-read this. You were referring to backward compatibility. Garrison On Feb 3, 2010, at 12:11, Garrison Venn wrote: > Hi Christophe, > > So this is a pain, but we are dealing with a pre-release. Until the 2.7 freeze the source should continue to churn. > > Regards > > Garrison > > On Feb 3, 2010, at 11:34, Christophe de Dinechin wrote: >

>> Also note that the documentation is unintentionally misleading. It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show "Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $" at the bottom, as if nothing had changed since then, when the code it displays is actually less than a week old... I guess the source code snippets are updated

On Wed, Feb 3, 2010 at 8:34 AM, Christophe de Dinechin <christophe at taodyne.com> wrote: > What guarantees does LLVM try to provide regarding source code compatibility? None. > Also note that the documentation is unintentionally misleading. It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show "Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17

On Wed, Feb 3, 2010 at 9:34 AM, Christophe de Dinechin <christophe at taodyne.com> wrote: > >>> Also note that the documentation is unintentionally misleading. It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show "Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $" at the bottom, as if nothing had changed since then, when

On Feb 3, 2010, at 8:34 AM, Christophe de Dinechin wrote: > Also note that the documentation is unintentionally misleading. It's very confusing for http://llvm.org/docs/tutorial/LangImpl4.html to show "Last modified: $Date: 2007-10-17 11:05:13 -0700 (Wed, 17 Oct 2007) $" at the bottom, as if nothing had changed since then, when the code it displays is actually less than a week

On 3 févr. 2010, at 17:54, Eli Friedman wrote: > On Wed, Feb 3, 2010 at 8:34 AM, Christophe de Dinechin > <christophe at taodyne.com> wrote: >> What guarantees does LLVM try to provide regarding source code compatibility? > > None. And this is a good thing because... ? Christophe

On Feb 3, 2010, at 12:26 PM, Christophe de Dinechin wrote: > On 3 févr. 2010, at 17:54, Eli Friedman wrote: > >> On Wed, Feb 3, 2010 at 8:34 AM, Christophe de Dinechin >> <christophe at taodyne.com> wrote: >>> What guarantees does LLVM try to provide regarding source code compatibility? >> >> None. > > And this is a good thing because... ?

I found the problem : my code sets JITEmitDebugInfo after creating the JIT. This causes the JITDwarfEmitter DE to not be constructed in the ctor of JITEmitter (JITEmitter.cpp around line 375). Not sure if it's documented anywhere that JITEmitDebugInfo must be set before constructing the JIT, but looking at the code, it makes sense. Easy enough to fix on my side. Christophe On 19 avr. 2011,

Hello, I'd like some advice on a crash that we have observed on MacOSX with the 2.8 and 2.9 releases of LLVM, but not on the top of trunk. The crash is a null-deref in llvm::JITDwarfEmitter::EmitDwarfTable : Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x0000000100852203 in llvm::JITDwarfEmitter::EmitDwarfTable

JIT::runJITOnFunctionUnlocked makes sure that functions referenced by the current function are JIT-ed. In my case, I may be compiling foo(), during which I notice that I need to build bar(), which refers to foo(). The compiler dies JIT-ing foo() because it's not done yet. Specifically, I'm in the middle of generating one of the BBs of foo(), so it doesn't have a terminating instruction

Hi Duncan, On 7 janv. 2011, at 01:00, Duncan Sands wrote: > LTO is for doing optimizations that are only valid when the module contains > everything that is needed to build the final executable. So adding a flag to > say "not everything is there after all" makes no sense to me. And indeed, everything is there when I call LTO. The flag is not "not everything is there

Hi, I'm a cs326 student that uses LLVM for our MP. While some of the COOL program can be run seamlessly, I get the following assertion error for many of them. lli: Pass.cpp:95: bool llvm::FunctionPassManager::run(llvm::Function&): >> Assertion `(&F == mF) && "ModuleProvider does not contain this >> function!"' failed. >> >> It seems

On Wed, 14 Apr 2004, Alex Li wrote: > Hi Chris, > > Thanks for responding so quickly, here's the stack trace. Okay, try applying this patch to your llvm/lib/VMCore/Pass.cpp file. It seems to have been in CVS since February 9, I assume that your tarball predates that. If this doesn't fix it, I'm not sure that there is anything that I can do, as I don't have the files you

On 25 nov. 2010, Renato Golin <rengolin at systemcall.org> wrote: > I don't see how you can have dominance between a normal block and a > cleanup block. Clean-up landing pads should never use user code (since > they don't exist in userland). [...] > In essence, in compiler generated landing pads, you should never > generate a use of user values. But if XYZ is user

On Sun, 15 Jul 2007, Paolo Invernizzi wrote: > First, I'm not sure if deleting the ExecutionEngine is all I need to > clean-up... so I started with a minimal test just to check Is this llvm 2.0 or llvm svn head? Several minor memory leaks have been fixed since llvm 2.0. -Chris > int main( int argc, char **argv ){ > while( true ){ > Module *M = new

First, I'm not sure if deleting the ExecutionEngine is all I need to clean-up... so I started with a minimal test just to check int main( int argc, char **argv ){ while( true ){ Module *M = new Module("M"); Function *F = cast<Function>(M->getOrInsertFunction("F", Type::Int32Ty, (Type*)0)); BasicBlock *BB = new

On 5 sept. 2011, at 17:48, Duncan Sands wrote: > since the result of a multiply doesn't depend on the signedness, I find it > strange that your target differentiates between them. What I'm saying is > that if you have (say) two i32 numbers a and b and you do a signed multiply: > c = a *s b > and an unsigned multiply > d = a *u b > then c and d are the same number

Hello, Following the tutorial "Kaleidoscope: Adding JIT and Optimizer Support", I found a Segmentation fault when I try to execute it. I am new in the neighbourhood, so I don't know what is wrong. Could you help me with that? I am working with the last version of LLVM (2.5). The code in chapter 2 and 3 works good, but the code in the chapter 4 did not work. Below are the detail of

I've been following this guide: http://llvm.org/docs/tutorial/LangImpl4.html and am getting an error when trying to create an execution engine. When running this code: executionEngine = llvm::EngineBuilder(module).setErrorStr(&errStr).create(); errStr contains: "Interpreter has not been linked in." I'm using this command to build: g++ -g errors.o lexer.o parser.o lang.o