search for: removefileonsignal

....mapVirtualFile( filename, sourcecode ); bool ret = ti.run(); In order to speed up compilation of several sources, I call the above code concurrently in separate threads, with each thread compiling its own source code. However, this does not work because clang::CompilerInstance calls llvm::Sys::RemoveFileOnSignal which in turn calls RegisterHandlers() which is not re-entrant. Is there a way to make RegisterHandlers() re-entrant? I do call llvm::start_multi_threaded() before any of this, hoping that it will make llvm routines thread-safe, but to no avail. Also, is there any other way of doing parallel comp...

...file: /var/cvs/llvm/llvm/lib/System/Win32/Signals.cpp,v > retrieving revision 1.10 > diff -u -r1.10 Signals.cpp > --- lib/System/Win32/Signals.cpp 5 Nov 2004 22:15:36 -0000 1.10 > +++ lib/System/Win32/Signals.cpp 15 Nov 2004 08:35:34 -0000 > @@ -72,7 +72,7 @@ > } > > // RemoveFileOnSignal - The public API > -void sys::RemoveFileOnSignal(const std::string &Filename) { > +void sys::RemoveFileOnSignal(const sys::Path &Filename) { > RegisterHandler(); > > if (CleanupExecuted) > @@ -81,7 +81,7 @@ > if (FilesToRemove == NULL) > FilesToRemove...

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>

...Function *function = node->getFunction(); StringRef str = function->getName(); return false; } }; And when I run the pass with opt, I get: 0 libLLVM-2.7.dylib 0xe0b33d28 llvm::sys::RWMutexImpl::writer_release() + 424 1 libLLVM-2.7.dylib 0xe0b34607 llvm::sys::RemoveFileOnSignal(llvm::sys::Path const&, std::string*) + 1143 2 libSystem.B.dylib 0x002632bb _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 18446744073707048303 4 LLVMHello.dylib 0x0002eba8 (anonymous namespace)::Hello::runOnSCC(std::vector<llvm::CallGraphNode*, std::allocator<llvm::...

...inux and MacOS >are already verified. > >The implementation of the lib/System interface should work on Solaris, >BSD, and perhaps a few other Unix systems. If you run into problems, >please let me know. Right now, the only thing that should affect any >tool other than llvmc is the RemoveFileOnSignal and >PrintStackTraceOnErrorSignal functions. These have been moved out of >lib/Support and into lib/System. > >Until I can get some hardware for each kind of system (should happen >this fall), I would like to ask for volunteers to assist in the testing >and porting of lib/System t...

...LLVMSupport.a(Signals.o): In function `llvm::sys::SetInterruptFunction(void (*)())': Signals.cpp:(.text+0x6c8): undefined reference to `llvm::sys::MutexImpl::acquire()' /home/ruben/mingw-w64/toolchain/linux64mingw64/llvm-clang/Release/lib/libLLVMSupport.a(Signals.o): In function `llvm::sys::RemoveFileOnSignal(llvm::sys::Path const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*)': Signals.cpp:(.text+0x790): undefined reference to `llvm::sys::MutexImpl::acquire()' /home/ruben/mingw-w64/toolchain/linux64mingw64/llvm-clang/Release/lib/libLLVMSupport.a...

...> In function `llvm::sys::SetInterruptFunction(void (*)())': > Signals.cpp:(.text+0x6c8): undefined reference to > `llvm::sys::MutexImpl::acquire()' > /home/ruben/mingw-w64/toolchain/linux64mingw64/llvm-clang/Release/lib/libLLVMSupport.a(Signals.o): > In function `llvm::sys::RemoveFileOnSignal(llvm::sys::Path const&, > std::basic_string<char, std::char_traits<char>, std::allocator<char> >> *)': > Signals.cpp:(.text+0x790): undefined reference to > `llvm::sys::MutexImpl::acquire()' > /home/ruben/mingw-w64/toolchain/linux64mingw64/llvm-clang/Rel...

...> > > >The implementation of the lib/System interface should work on Solaris, > > >BSD, and perhaps a few other Unix systems. If you run into problems, > > >please let me know. Right now, the only thing that should affect any > > >tool other than llvmc is the RemoveFileOnSignal and > > >PrintStackTraceOnErrorSignal functions. These have been moved out of > > >lib/Support and into lib/System. > > > > > >Until I can get some hardware for each kind of system (should happen > > >this fall), I would like to ask for volunteers to ass...

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

...the "external node". Ciao, Duncan. > return false; > } > }; > > And when I run the pass with opt, I get: > > 0 libLLVM-2.7.dylib 0xe0b33d28 > llvm::sys::RWMutexImpl::writer_release() + 424 > 1 libLLVM-2.7.dylib 0xe0b34607 > llvm::sys::RemoveFileOnSignal(llvm::sys::Path const&, std::string*) + > 1143 > 2 libSystem.B.dylib 0x002632bb _sigtramp + 43 > 3 libSystem.B.dylib 0xffffffff _sigtramp + 18446744073707048303 > 4 LLVMHello.dylib 0x0002eba8 (anonymous > namespace)::Hello::runOnSCC(std::vector<llvm::CallGraphNode*, >...

...int Sig) { ... SignalsMutex.acquire(); RemoveFilesToRemove(); ... } We can also find following code snippet in the same file: void llvm::sys::RunInterruptHandlers() { SignalsMutex.acquire(); RemoveFilesToRemove(); SignalsMutex.release(); } Similarly, there are SetInterruptFunction, RemoveFileOnSignal, DontRemoveFileOnSignal I am afraid there is deadlock risk if llvm running in multithread mode, the case it is designed to safeguard. Suppose, say when some thread runs into RunInterruptHandlers and acquire the Mutex, then it is preemptied by scheduler, and before it is reselected by scheduler, o...

...on most Unix systems. Linux and MacOS are already verified. The implementation of the lib/System interface should work on Solaris, BSD, and perhaps a few other Unix systems. If you run into problems, please let me know. Right now, the only thing that should affect any tool other than llvmc is the RemoveFileOnSignal and PrintStackTraceOnErrorSignal functions. These have been moved out of lib/Support and into lib/System. Until I can get some hardware for each kind of system (should happen this fall), I would like to ask for volunteers to assist in the testing and porting of lib/System to: Darwin, Solaris 8/9,...

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached