search for: raw_fd_ostreams

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

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 format of “A:B:C”, is it possible that I got “A1:B2:C1” and

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.

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

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 you!"\n";

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 creates problems, even if not used. - D. 2012/11/29 Dan Gohman <dan433584 at gmail.com> > On Wed, Nov 28, 2012 at

It looks like some kind of file IO buffer overflow. I'm not dumping 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

So I did a clean checkout and build and still have this issue, did something changed with the way/when it's getting flushed? My old revision did not have this issue, this is an issue strictly with LLVM it seems. On Fri, Oct 26, 2012 at 3:27 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > It looks like some kind of file IO buffer overflow. I'm not dumping any > long strings

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 exactly what I am trying to write > out. > > I see. > > For

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

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

Hello all, I am looking into using LLVM streams more extensively 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

On Wed, Dec 7, 2016 at 10:02 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Dec 7, 2016, at 1:52 AM, Viacheslav Nikolaev via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > This code from raw_ostream.h is really racy: > > > > raw_ostream &operator<<(StringRef Str) { > > // Inline fast path,

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

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

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

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 this what we want?