search for: erasefromdisk

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 PathV1, could we fix? ...Takumi 2012/5/29 Manuel Klimek <klimek at google.c...

...getting following error on Ubuntu. My gcc is gcc version 4.4.5. Please let me know if you have any comments/suggestions. In file included from /home/janarbek/Work/llvm/llvm/lib/Support/Path.cpp:299: /home/janarbek/Work/llvm/llvm/lib/Support/Unix/Path.inc: In member function ‘bool llvm::sys::Path::eraseFromDisk(bool, std::string*) const’: /home/janarbek/Work/llvm/llvm/lib/Support/Unix/Path.inc:714: error: ‘unlink’ was not declared in this scope make[1]: *** [/home/janarbek/Work/llvm/llvm_obj/lib/Support/Release+Asserts/Path.o] Error 1 make[1]: Leaving directory `/home/janarbek/Work/llvm/llvm_obj/lib/Suppo...

...see the following warnings when building. I'm not sure how to fix any of them. The last one looks like it might be serious (seems like a job for Chris). llvm[1]: Compiling Path.cpp for Release build In file included from Path.cpp:270: Unix/Path.inc: In member function ‘bool llvm::sys::Path::eraseFromDisk(bool, std::string*) const’: Unix/Path.inc:661: warning: ignoring return value of ‘int system(const char*)’, declared with attribute warn_unused_result llvm[1]: Compiling raw_ostream.cpp for Release build raw_ostream.cpp: In member function ‘virtual void llvm::raw_fd_ostream::flush_impl()’: raw_os...

...wing error on Ubuntu. My gcc is gcc version 4.4.5. Please let me know if you have any comments/suggestions. > > In file included from /home/janarbek/Work/llvm/llvm/lib/Support/Path.cpp:299: > /home/janarbek/Work/llvm/llvm/lib/Support/Unix/Path.inc: In member function ‘bool llvm::sys::Path::eraseFromDisk(bool, std::string*) const’: > /home/janarbek/Work/llvm/llvm/lib/Support/Unix/Path.inc:714: error: ‘unlink’ was not declared in this scope > make[1]: *** [/home/janarbek/Work/llvm/llvm_obj/lib/Support/Release+Asserts/Path.o] Error 1 > make[1]: Leaving directory `/home/janarbek/Work/llvm/llv...

...std::cerr << argv[0] << ": target does not support generation of this" << " file type!\n"; if (Out != &std::cout) delete Out; // And the Out file is empty and useless, so remove it now. sys::Path(OutputFilename).eraseFromDisk(); return 1; } Passes.doInitialization(); // Run our queue of passes all at once now, efficiently. for (Module::iterator I = mod.begin(), E = mod.end(); I != E; ++I) if (!I->isExternal()) Passes.run(*I); Passes.doFinalization();...

Hi folks, just installed the new llvm 1.9 build and noticed that my code no longer worked. It seems something has changed with addPassesToEmitFile(). First, the arguments to that method changed so that it no longer takes a PassManager, but only a FunctionPassManager. Instead there is a addPassesToEmitWholeFile() method, but that is marked as optional, and when I change my code to

.... > > Thanks in advance. > > make[1]: Entering directory > `/home/janarbek/Work/llvm/RELEASE_29/final/trunk/lib/Support' > llvm[1]: Compiling Path.cpp for Debug+Asserts build > In file included from Path.cpp:299: > Unix/Path.inc: In member function ‘bool llvm::sys::Path::eraseFromDisk(bool, > std::string*) const’: > Unix/Path.inc:716: error: ‘unlink’ was not declared in this scope > make[1]: *** > [/home/janarbek/Work/llvm/RELEASE_29/final/trunk/lib/Support/Debug+Asserts/Path.o] > Error 1 > make[1]: Leaving directory > `/home/janarbek/Work/llvm/RELEASE_29/fi...

...other machine with gcc version of 4.3. Thanks in advance. make[1]: Entering directory `/home/janarbek/Work/llvm/RELEASE_29/final/trunk/lib/Support' llvm[1]: Compiling Path.cpp for Debug+Asserts build In file included from Path.cpp:299: Unix/Path.inc: In member function ‘bool llvm::sys::Path::eraseFromDisk(bool, std::string*) const’: Unix/Path.inc:716: error: ‘unlink’ was not declared in this scope make[1]: *** [/home/janarbek/Work/llvm/RELEASE_29/final/trunk/lib/Support/Debug+Asserts/Path.o] Error 1 make[1]: Leaving directory `/home/janarbek/Work/llvm/RELEASE_29/final/trunk/lib/Support' make: **...

The patch does inseret unistd.h as below. However, I am still getting exactly same error when I do make.if you have any suggestions please let me know. #if HAVE_UNISTD_H #include <unistd.h> #endif   =========================================== Phone : 82-42-860-1838 Fax : 82-42-860-6790 Cell Phone: 82-10-7599-1981 =========================================== --- On Mon, 10/24/11, Eli

.... > > Thanks in advance. > > make[1]: Entering directory > `/home/janarbek/Work/llvm/RELEASE_29/final/trunk/lib/Support' > llvm[1]: Compiling Path.cpp for Debug+Asserts build > In file included from Path.cpp:299: > Unix/Path.inc: In member function ‘bool llvm::sys::Path::eraseFromDisk(bool, > std::string*) const’: > Unix/Path.inc:716: error: ‘unlink’ was not declared in this scope > make[1]: *** > [/home/janarbek/Work/llvm/RELEASE_29/final/trunk/lib/Support/Debug+Asserts/Path.o] > Error 1 > make[1]: Leaving directory > `/home/janarbek/Work/llvm/RELEASE_29/fi...

Hello all, I am currently working with LLVM and make use of the debug output from llc. The SelectionDAG dumping features are especially interesting to me since I am looking for operation patterns that allow me to decide which custom instructions can be added to a processor in order to improve the performance. Providing a -view-dag-combine1-dags option (and its friends) to llc show the

...wing error on Ubuntu. My gcc is gcc version 4.4.5. Please let me know if you have any comments/suggestions. > > In file included from /home/janarbek/Work/llvm/llvm/lib/Support/Path.cpp:299: > /home/janarbek/Work/llvm/llvm/lib/Support/Unix/Path.inc: In member function ‘bool llvm::sys::Path::eraseFromDisk(bool, std::string*) const’: > /home/janarbek/Work/llvm/llvm/lib/Support/Unix/Path.inc:714: error: ‘unlink’ was not declared in this scope > make[1]: *** [/home/janarbek/Work/llvm/llvm_obj/lib/Support/Release+Asserts/Path.o] Error 1 > make[1]: Leaving directory `/home/janarbek/Work/llvm/llv...

...; + >>> +  return true; >>> +} >>> + >>> +bool >>>  Path::canExecute() const { >>>   if (0 != access(path.c_str(), R_OK | X_OK )) >>>     return false; >>> @@ -723,7 +741,7 @@ >>> >>>  bool >>>  Path::eraseFromDisk(bool remove_contents, std::string *ErrStr) const { >>> -  // Get the status so we can determin if its a file or directory >>> +  // Get the status so we can determine if its a file or directory >>>   struct stat buf; >>>   if (0 != stat(path.c_str(), &buf)) {...

On 24 October 2011 15:50, Ryan Taylor <ryta1203 at gmail.com> wrote: > Nick, > > Oh, sorry. So there are lots of "void" operations, I basically just want > to print out the operation name, it's dest operands and source operands, What's a dest operand? The term "operand" in LLVM always refers to the inputs (ie., an add has two operands). >

LLVMers, The 2.4 pre-release is available for testing: http://llvm.org/prereleases/2.4/ If you have time, I'd appreciate anyone who can help test the release. Please do the following: 1) Download/compile llvm source, and either compile llvm-gcc source or use llvm-gcc binary. 2) Run make check, send me the testrun.log 3) Run "make TEST=nightly report" and send me the

LLVMers, The 2.5 pre-release is available for testing: http://llvm.org/prereleases/2.5/ If you have time, I'd appreciate anyone who can help test the release. Please do the following: 1) Download/compile llvm source, and either compile llvm-gcc source or use llvm-gcc binary (please compile llvm-gcc with fortran if you can). 2) Run make check, send me the testrun.log 3) Run "make

Nick, Unfortunately this doesn't answer my question I don't think. It seems that -instnamer, as you mention, names the instructions but still does not name the local variables. So there really is no way to do this shy of creating (or basically copying) the API from AsmWriter (seems very dedundant to me)? This seems like a large failing? On Fri, Oct 21, 2011 at 7:03 PM, Nick

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