similar to: [LLVMdev] Clang API parsing of the destructor

On Fri, Sep 21, 2012 at 12:22 PM, Kamaljit Lall <klall at factset.com> wrote: > I am using the clang API (version 3.1 - trunk 153913) to compile some > very simple code as follows**** > > class MyClass > { > ~MyClass() ; > > }; > > MyClass::~MyClass() > { > > } > > int main() > { > return 0; > } **** > > My problem is that

Manuel, After the discussion at last night, I have agreed that GetTemporaryDirectory() on Win32 would do bad thing, thank you. dir = GetTemporaryDirectory(); dir.eraseFromDisk(erase_contents = true); dir = GetTemporaryDirectory(); /* It doesn't create anything on Win32 due to caching */ I suppose Manuel wants GetTemporaryDirectory() to keep semantics similar mkdtemp(3). Though it is in

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());

You will need to link to the LLVM/clang libraries. To get the correct flags, you can run: ./llvm-config --ldflags --libs and use the flags reported. On 7/10/2012 11:35 AM, NY Knicks Fan wrote: > OK. Thanks. I now get the following error (which appears to be a > problem w/ the tutorial itself?): > > $ /home/ubuntu/bin/bin/clang++ -I /home/ubuntu/bin/include/ >

Hi Ashok, $ cd bin/bin $ ./llvm-config --ldflags --libs -L/home/ubuntu/bin/lib   -ldl -lpthread -lLLVMAsmParser -lLLVMTableGen -lLLVMDebugInfo -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMJIT -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInstrumentation -lLLVMInterpreter

You need to link in the libclang* as well. On 7/10/2012 1:22 PM, NY Knicks Fan wrote: > Hi Ashok, > > $ cd bin/bin > $ ./llvm-config --ldflags --libs > -L/home/ubuntu/bin/lib -ldl -lpthread > -lLLVMAsmParser -lLLVMTableGen -lLLVMDebugInfo -lLLVMX86Disassembler > -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter > -lLLVMX86Desc -lLLVMX86Info

OK.  Thanks.  I now get the following error (which appears to be a problem w/ the tutorial itself?): $ /home/ubuntu/bin/bin/clang++ -I /home/ubuntu/bin/include/  -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS tutorial1.cpp/tmp/tutorial1-LQ71fW.o: In function `main': tutorial1.cpp:(.text+0x42): undefined reference to `llvm::outs()' tutorial1.cpp:(.text+0x72): undefined reference to

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

Add -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS to your compilation flag. On 7/10/2012 11:23 AM, NY Knicks Fan wrote: > Hi Ashok, > > I created a new Ubuntu 12.04 virtual machine and followed directions > except that I know use your cmake command instead of configure, and I > got the error below. > > Any help is very much appreciated. > > > $

Hi, I am using clang::ToolInvocation class to compile some code in-memory: clang::tooling::ToolInvocation ti ( compilerArgs, new clang::EmitBCAction(), new clang::FileManager(clang::FileSystemOptions()) ); //filename is the name of the source file, e.g. "Somefile.cpp" //sourcecode contains the source of the file ti.mapVirtualFile( filename,

Hi, I'm not sure if this is a libclang, llvm::cl or clang-interpreter issue so I'll try posting here for a response. I am using libclang as a frontend to the LLVM JIT (3.3 release). I started from the clang-interpreter example and have everything working (given a C/C++ source file I can have it JIT'd to memory and executed) for a single run. When I try to compile a second source

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

Hi, I have downloaded version 3.0 of LLVM and Clang and built them as shared libraries (on Windows, Linux and Mac OS X) using the following steps: cd <WHERE-llvm-3.0.tar.gz-IS> tar xvzf llvm-3.0.tar.gz cd llvm-3.0.src/tools tar xvzf ../../clang-3.0.tar.gz mv clang-3.0.src clang cd ../.. mkdir build cd build ../llvm-3.0.src/configure --disable-docs --enable-shared

I am using the Clang c++ API. I have a blocking issue because the builtin __builtin_va_list clang isn't defined. Here is the error: ..lib/clang/3.2/include/stdarg.h:30:9: error: unknown type name '__builtin_va_list'; did you mean '__builtin_va_list'? typedef __builtin_va_list va_list; >From what I've read, this builtin is target dependent. This builtin is not defined

HI all, Here in the JUCE team, we are working on porting the Projucer <https://www.juce.com/releases/projucer-juce-4> C++ live coding engine to Windows. Our main challenge now is how to catch C++ exceptions in runtime-compiled code on Windows. This doesn’t work for us and we’re quite stuck at this point. I recently had a chat about this with Chandler Carruth at C++Now. Chandler suggested

Hi, Have anybody recently built LLVM in Debug mode /within/ space requirements from the Getting Started doc? https://llvm.org/docs/GettingStarted.html#hardware > An LLVM-only build will need about 1-3 GB of space. A full build of LLVM and Clang will need around 15-20 GB of disk space. From my experience this numbers looks drastically low. On FreeBSD my recent builds consumed more than