similar to: [LLVMdev] libclang JIT frontend

Heres my full code listing, im totally stuck. // Whistle.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include "clang/CodeGen/CodeGenAction.h" #include "clang/Driver/Compilation.h" #include "clang/Driver/Driver.h" #include "clang/Driver/Tool.h" #include

This thread may help: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-June/009507.html On Sun, Aug 15, 2010 at 2:50 AM, gafferuk <gafferuk at gmail.com> wrote: > > Hi, how do I compile c code from a char array in clang? > > Im using code from the interpreter example. > Thanks. > > char *cCode; // the char array > // fill array with code goes here... > > >

Hi, how do I compile c code from a char array in clang? Im using code from the interpreter example. Thanks. char *cCode; // the char array // fill array with code goes here... // Initialize a compiler invocation object from the clang (-cc1) arguments. const driver::ArgStringList &CCArgs = Cmd->getArguments(); llvm::OwningPtr<CompilerInvocation> CI(new CompilerInvocation);

I don't know how ccons works, but it may do what you need. http://code.google.com/p/ccons/ Le 15 août 2010 à 14:48, gafferuk a écrit : > > no, does not help, ive already looked at it. > > > > none none-17 wrote: >> >> This thread may help: >> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-June/009507.html >> >> On Sun, Aug 15, 2010 at

no, does not help, ive already looked at it. none none-17 wrote: > > This thread may help: > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-June/009507.html > > On Sun, Aug 15, 2010 at 2:50 AM, gafferuk <gafferuk at gmail.com> wrote: > >> >> Hi, how do I compile c code from a char array in clang? >> >> Im using code from the interpreter

I tried what you said, now I get: LLVM ERROR: Program used external function 'yipee' which could not be resolved! Stack dump: 0. Running pass 'X86 Machine Code Emitter' on function '@main' did not even get as far as a breakpoint. Óscar Fuentes wrote: > > gafferuk <gafferuk at gmail.com> writes: > >> Im confused. The function i wish to call is

gafferuk <gafferuk at gmail.com> writes: > Im confused. The function i wish to call is a return type of int. > Im calling it with int dd = yipee(1); > > What's wrong? Declare the function: int yipee(int); int main() { int dd = yipee(1); return 0; } If that still crashes, put a breakpoint on `yipee' and see if the execution gets there, if the argument is

why llvm contains IntrusiveRefCntPtr instead of using only std::shared_ptr? IntrusiveRefCntPtr widely used in llvm and clang source code. Due to better performance? for example in main func of clang frontend: int cc1_main(ArrayRef<const char *> Argv, const char *Argv0, void *MainAddr) { ensureSufficientStack(); std::unique_ptr<CompilerInstance> Clang(new CompilerInstance());

Hi Sanjiv, On Wed, Jul 1, 2009 at 7:02 PM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote: > I found out the problem. Looks like I can not rely on argv[0] to contain the > full path of the executable always. Yeah, that's what I was thinking. > Can I rely on: > static Path GetMainExecutable(const char *argv0, void *MainAddr); Clang relies on it. According to

Hi, I'm having troubles to add a custom include path to a clang based C++ parser. I'd like to properly support this opencv code under Linux: ... #include "cv.h" #include "highgui.h" ... This is what I'm using: TheCompInst->getHeaderSearchOpts().AddPath(StringRef("/usr/include/opencv"),clang::frontend::Quoted ,false, true, false, false, false);

Hi, I'm having troubles to add a custom include path to a clang based C++ parser. I'd like to properly support this opencv code under Linux: ... #include "cv.h" #include "highgui.h" ... This is what I'm using: TheCompInst->getHeaderSearchOpts().AddPath(StringRef("/usr/include/opencv"),clang::frontend::Quoted ,false, true, false, false, false);

Thanks. This framework has made writing a driver a pleasure. It couldn't have been easier to write a driver. - Sanjiv Mikhail Glushenkov wrote: > Hi Sanjiv, > > On Wed, Jul 1, 2009 at 7:02 PM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote: > >> I found out the problem. Looks like I can not rely on argv[0] to contain the >> full path of the executable

I found out the problem. Looks like I can not rely on argv[0] to contain the full path of the executable always. Can I rely on: static Path GetMainExecutable(const char *argv0, void *MainAddr); is it Cross-platform? What to pass for second parameter here. C++ forbids taking address of "main", and the "Main" of CompilerDriver is in a shared object here. - Sanjiv Sanjiv

Hi, I have written a pass to compute the reaching definitions for variables using loads and stores. The class for this pass is named ReachingDef and the pass itself is registered as reaching-def. The compiled reaching-def.so file goes to llvm-home/Release/lib/. This pass is used by another function pass that is registered as iel and the class is named SIL. I have setup AnalysisUsage object of SIL

On Apr 5, 2010, at 7:10 PM, funceval wrote: > opt -load ../../../Release/lib/iel.so > <premain>: CommandLine Error: Argument 'inline-threshold' defined > more than once! > opt: CommandLine Error: Argument 'inline-threshold' defined more > than once! > Error opening '../../../Release/lib/iel.so': ../../../Release/lib/ > iel.so: undefined

> I'm linking a program (my ellsif driver) that basically brings in most > of the LLVM stuff: bitcode reading, optimizations, linking, and target > code generation. > > All of a sudden, I'm getting the following when I run: > [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i test/sieve.i -time-actions > -O5 > <premain>: CommandLine Error: Argument

I'm linking a program (my ellsif driver) that basically brings in most of the LLVM stuff: bitcode reading, optimizations, linking, and target code generation. All of a sudden, I'm getting the following when I run: [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i test/sieve.i -time-actions -O5 <premain>: CommandLine Error: Argument 'machine-licm' defined more than once!

On Sun, 20 May 2007, Bram Adams wrote: > Op 19-mei-07, om 00:39 heeft Chris Lattner het volgende geschreven: >> Anton is right. You should be able to use -fno-builtins to disable >> this. > > Thanks, that did the trick. > > Some final remarks (my app works again :-)): > * llvm.va_start and similar intrinsics now have an i8* arg instead > of an sbyte** ok >

Hi, Op 19-mei-07, om 00:39 heeft Chris Lattner het volgende geschreven: > Anton is right. You should be able to use -fno-builtins to disable > this. Thanks, that did the trick. Some final remarks (my app works again :-)): * llvm.va_start and similar intrinsics now have an i8* arg instead of an sbyte** * For some reason the Arguments of a Function are now circularly linked,

On Tue, 22 May 2007 23:52:46 -0700 (PDT) Chris Lattner <sabre at nondot.org> wrote: >On Sun, 20 May 2007, Bram Adams wrote: >> On a related note: while using llvmc I have some test cases where the >> following error now pops up on Linux X86 (not on OSX): >> >> <premain>: CommandLine Error: Argument 'debug' defined more than once! >> llvmc: