search for: raw_fd_ostream

Dear all, Consider there is a program that writes to stdout using two different raw_fd_ostream-s: #include "llvm/LLVMContext.h" #include "llvm/Module.h" #include "llvm/Support/raw_ostream.h" using namespace llvm; int main() { raw_fd_ostream S(STDOUT_FILENO, false); outs() << "Hello"; S << ", world!";...

On Wed, Nov 28, 2012 at 10:54 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > Dear all, > > Consider there is a program that writes to stdout using two different > raw_fd_ostream-s: raw_fd_ostream does buffered I/O, so it's not really meant to be used like this. > #include "llvm/LLVMContext.h" > #include "llvm/Module.h" > #include "llvm/Support/raw_ostream.h" > > using namespace llvm; > > int main() > { >...

Hi all, In a pass I’m using raw_fd_ostream to write a string to a file. Does raw_fd_ostream guarantee the write is atomic when I do parallel compilation (currently I’m using -j8)? I have some errs() to print information for debugging purposes and I saw that the printed information gets messed up sometime. If I’m writing a string with the fo...

Hello, The following describes an API change on trunk. The change is not in the 2.6 branch. The raw_fd_ostream class now defaults to overwriting its output file, and the F_Force flag which was introduced only recently is gone. There's a new F_Excl flag to support users wanting the behavior of returning an error if the file exists, though no one actually appears to want this. Accompanying this is...

Dan Gohman wrote: > Hello, > > The following describes an API change on trunk. The change is not in > the 2.6 branch. > > The raw_fd_ostream class now defaults to overwriting its output file, > and the > F_Force flag which was introduced only recently is gone. There's a > new F_Excl flag to > support users wanting the behavior of returning an error if the file > exists, though no one > actually appears to wa...

I'm getting seemingly odd SegFaults when writing out using a raw_fd_ostream in the current trunk (last version worked, believe it was 153818, or similar). Again, nothing in the release notes... should I be scanning the svn log? For example, I have something like: raw_fd_ostream fout("out.txt", errorStr=""); .... fout<<"Hello World, how are...

...ems, even if not used. - D. 2012/11/29 Dan Gohman <dan433584 at gmail.com> > On Wed, Nov 28, 2012 at 10:54 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > >> Dear all, >> >> Consider there is a program that writes to stdout using two different >> raw_fd_ostream-s: > > > raw_fd_ostream does buffered I/O, so it's not really meant to be used like > this. > > >> #include "llvm/LLVMContext.h" >> #include "llvm/Module.h" >> #include "llvm/Support/raw_ostream.h" >> >> using namespa...

...mping any long strings at one time, but I am keeping the file open for the entire run. I've yet to find a correlation to other C files. On Fri, Oct 26, 2012 at 3:17 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I'm getting seemingly odd SegFaults when writing out using a > raw_fd_ostream in the current trunk (last version worked, believe it was > 153818, or similar). Again, nothing in the release notes... should I be > scanning the svn log? > > For example, I have something like: > > raw_fd_ostream fout("out.txt", errorStr=""); > .... > f...

...ime, but I am keeping the file open for the entire > run. I've yet to find a correlation to other C files. > > > On Fri, Oct 26, 2012 at 3:17 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> I'm getting seemingly odd SegFaults when writing out using a >> raw_fd_ostream in the current trunk (last version worked, believe it was >> 153818, or similar). Again, nothing in the release notes... should I be >> scanning the svn log? >> >> For example, I have something like: >> >> raw_fd_ostream fout("out.txt", errorStr="&...

Note that raw_fd_ostream is not seekable, and hence will not be suitable as addPassesToEmitFile output stream. 2016-02-22 18:27 GMT+02:00 Rafael Espíndola <llvm-dev at lists.llvm.org>: > On 22 February 2016 at 11:16, Frank Winter <fwinter at jlab.org> wrote: > > TargetMachine::CGFT_AssemblyFile is...

On Aug 25, 2009, at 1:04 AM, Albert Graef wrote: > . For many applications > other than LLVM itself, the basic LLVM <=2.5 interface which just > overwrites existing files is all that's ever needed. On LLVM trunk, raw_fd_ostream is now back to overwriting files by default, as it is the unanimous preference among in-tree users (and out-of-tree users that I'm aware of). Dan

It seems that support for dumping text representation of LLVM objects to standard channels and C++ output streams was removed. My guess is that now we must use errs() instead of std::cerr, llvm::raw_fd_ostream instead of std::ofstream, etc. The changes are not trivial, as for instance llvm::raw_fd_ostream without flags fails if the file exists, but std::ofstream does not. The changes include using new names for flags that already exist on the standard namespace (F_Force instead of O_TRUNC, etc). Is all...

Dan Gohman wrote: > > On Aug 25, 2009, at 1:04 AM, Albert Graef wrote: >> . For many applications >> other than LLVM itself, the basic LLVM <=2.5 interface which just >> overwrites existing files is all that's ever needed. > > On LLVM trunk, raw_fd_ostream is now back to overwriting files by > default, as it is the unanimous preference among in-tree users (and > out-of-tree users that I'm aware of). But the raw_fd_ostream constructor is *still* incompatible with both LLVM <=2.5 and LLVM 2.6: LLVM 2.5: raw_fd_ostream(const char *Filen...

...in LLDB (which currently rolls it's own stream classes). One of the things that's missing for me to be able to do that is the ability to open a file with the O_CLOEXEC flag (to prevent us leaking file descriptors into the debugged process). So I tried adding a F_NonInheritable flag to the raw_fd_ostream constructor, which would map to O_CLOEXEC on unix, and non-inheritable handles on windows. However, I encountered a discrepancy in the current behavior there. The current behavior on unix is to make the file descriptors inheritable (as that is the platform default). On windows, the current behavio...

...ltiple threads at the same time. > > > > But imagine someone might get logs to dbgs() or errs() running the > backend for a target in multiple threads. > > These are unbuffered, I wouldn’t expect a race in the code you list above. > I believe it’ll always forward directly to raw_fd_ostream::write_impl(), > which is calling the libc ::write(). > > — > Mehdi > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -------------- next part ----...

On Thu, Nov 29, 2012 at 11:03 AM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > Hi Dan, Sean, > > Thanks for replies, > > So does it mean user is not expected to use any other stream for stdout, > but outs()? Although there is a comment "If you don't want this behavior, > don't use outs().", outs() is a static instance which always exists and

> On Dec 7, 2016, at 10:27 AM, Viacheslav Nikolaev <viacheslav.nikolaev at gmail.com> wrote: > > > I believe it’ll always forward directly to raw_fd_ostream::write_impl(), which is calling the libc ::write(). > > Do you mean raw_fd_ostream somehow overrides the operator<< the code for which I extracted? > I cannot see if that is so. And I really saw it didn't albeit in a very old master. No, I meant I didn’t see the race in the cod...

Albert Graef wrote: > I understand that. But in this specific case it would be very easy to > maintain, no? FWIW, suggested patch attached. That makes the LLVM 2.5 style raw_fd_ostream constructor work with the trunk (r80036). Note that this just adds a second constructor, existing code will continue to work as before. I'd be happy to prepare an analogous patch for the 2.6 release branch, just let me know. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, Univers...

Existing llvm code tends to use raw_ostream for writing files. But raw_ostream is not a good match for a linker for a couple of reasons: 1) When the linker creates an executable, the file needs the 'x' bit set. Currently raw_fd_ostream has no way to set that. 2) The Unix conformance suite actually has some test cases where the linker is run and the output file does exists but is not writable, or is not writable but is in a writable directory, or with funky umask values. raw_fd_ostream interface has no way to match those semant...

In llc's GetOutputStream we have this: raw_fd_ostream *FDOut = new raw_fd_ostream(OutputFilename.c_str(), /*Binary=*/true, Force, error); Why is Binary set true here? We don't know yet whether this is going to be an AsmFile or a MachOFile. Setting Binary=true causes the stream to be unbuffered. Is...