similar to: [LLVMdev] multithreaded use of llvm::sys::RemoveFileOnSignal

Hello! So I am running clang programmatically using clang::tooling::ToolInvocation, however I dont want anything to touch the disk. I am able to read from a virtual file using clang::tooling::ToolInvocation::mapVirtualFile , however I dont know how to output to a virtual file or just to an std::string or char* , I tried passing -o out.S -ivfsoverlay out.S but it still writes to disk and as

Hi, when I updated the sources today there were several small problems that stopped the windows version from compiling, here are the patches m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: win32patches.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041115/34634455/attachment.txt>

Hello, all: I have a problem want to discus with you, Chris someone should be the right person. In llvm-3.1.src/lib/support/unix/Signals.inc, in SignalHandler, we have: static RETSIGTYPE SignalHandler(int Sig) { ... SignalsMutex.acquire(); RemoveFilesToRemove(); ... } We can also find following code snippet in the same file: void llvm::sys::RunInterruptHandlers() {

Hi, My application generates some C code which I then compile using LLVM+Clang before running it. For the compilation side of things, I have a class which one of the methods (the CompilerEngine::compileCode() method in https://raw.github.com/opencor/opencor/llvm_3.3/src/plugins/misc/Compiler/sr c/compilerengine.cpp) is based on the code from the clang-interpreter example

Hi, I can confirm this problem. We use clang's libtooling ToolInvocation object and the second module fails to compile even through it's a completely fresh instance. Adding -fno-vectorize explicitly seems to work around this problem, but does anyone know a real fix? ciao, Mario Am 20.06.13 15:07, schrieb Alan Garny: > My application generates some C code which I then compile using

Hi, I'm trying to use CallGraphSCCPass, but I keep getting a bus error. I can reproduce the problem quite easily using the lib/Transforms/Hello example. I simply mix in these changes: #include "llvm/CallGraphSCCPass.h" ... struct Hello : public CallGraphSCCPass { static char ID; // Pass identification, replacement for typeid Hello() : CallGraphSCCPass(&ID) {}

Currently a power failure or other hard crash can cause lld leave a temporary file around. The same is true for other llvm tools. As an example, put a breakpoint in Writer.cpp:236 ("writeBuildId()") and restart the run a few times. You will get t.tmp43a735a t.tmp4deeabb t.tmp9bacdd3 t.tmpe4115c4 t.tmpeb01fff The same would happen if there was a fatal error between the

Hi, I'm getting a returning build failure when building a linux->windows crosscompiler out of LLVM/Clang. Attached is config.log and below is the output of "make VERBOSE=1" llvm[2]: Linking Release executable FileCheck (without symbols) g++ -I/home/ruben/mingw-w64/toolchain/linux64mingw64/llvm-clang/include

iMac Intel Core Duo; OS X 10.4.8; Java 1.5.0_06; R 2.4.1; JGR 1.4-14; rJava 0.4-12; iplots 1.0-5 I'm unable to get JGR or iplots to load using "library(JGR)" or "library(iplots)", respectively. This feels like it might be a classpath or Mac look-and-feel issue, but I'm not sure where to go with it at this point. I've searched the fora and web to no avail. Any

I would like to volunteer for the port of Interix and Win32 platforms, if no one objects against this. /Henrik --- Got Freedom? Software Freedom Day 2004 - 28th of August http://www.softwarefreedomday.org/ --- >From: Reid Spencer <reid at x10sys.com> >Reply-To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >To: LLVMdev List <llvmdev at cs.uiuc.edu>

Hi Ruben, Try adding a --build=x86_64-gnu-linux option to configure as well. I don't have that configuration locally, so I can't check to be certain, but IIRC, our configure wants all three for a cross compile like this. -Jim On Aug 21, 2011, at 7:19 AM, Ruben Van Boxem wrote: > Hi, > > I'm getting a returning build failure when building a linux->windows >

Hi Reid, I downloaded the latest source code and ran configure (I suppose it was that you did mean). The result is: --------------- checking build system type... i586-pc-interix3 --------------- Otherwise, please correct me. /Henrik --- Got Freedom? Software Freedom Day 2004 - 28th of August http://www.softwarefreedomday.org/ --- >From: Reid Spencer <reid at x10sys.com>

Morten, I've applied these patches. Thanks for the updates! Reid. On Mon, 2004-11-15 at 01:26, Morten Ofstad wrote: > Hi, > > when I updated the sources today there were several small problems that > stopped the windows version from compiling, here are the patches > > m. > > > ______________________________________________________________________ > Index:

Like this: llvm[1]: Compiling Signals.cpp for Debug build In file included from Signals.cpp:33: Win32/Signals.inc:262: error: `sys' has not been declared Win32/Signals.inc: In function `void AddSignalHandler(void (*)(void*), void*)': Win32/Signals.inc:266: error: `KillSigs' was not declared in this scope Win32/Signals.inc:266: error: `KillSigsEnd' was not declared in this scope

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 I get the error message: test.cpp:20:10: error: destructor cannot have a return type MyClass::~MyClass() If someone can point me to the right direction that would be great. It compiles fine if

On Mar 8, 2009, at 4:21 AM, Lennart Augustsson wrote: > Like this: > > llvm[1]: Compiling Signals.cpp for Debug build > In file included from Signals.cpp:33: > Win32/Signals.inc:262: error: `sys' has not been declared > Win32/Signals.inc: In function `void AddSignalHandler(void (*) > (void*), void*)': > Win32/Signals.inc:266: error: `KillSigs' was not declared

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

I'm trying to compile the top version of LLVM with MinGW, but I'm getting compilation errors. They seem to be caused by the changes in rev 66072. Has anyone compiled on MinGW? Since I just installed MinGW on this computer it could be my problem. (I noticed that LLVM 2.5 still doesn't come with binaries for the libraries on MinGW.) -- Lennarft

On Sunday 08 March 2009 01:42:42 Lennart Augustsson wrote: > I'm trying to compile the top version of LLVM with MinGW, but I'm > getting compilation errors. What kind of errors? Ciao, Duncan.

Hi, After building llvm with clang the llvmc tests are failing with: llvmc: Node llc is not in graph Anyone else see this ? (TOT llvm & clang) -Argiris