similar to: [LLVMdev] [API CHANGE (on trunk)] raw_fd_ostream defaults to overwrite

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

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

On Aug 23, 2009, at 4:29 PM, Albert Graef <Dr.Graef at t-online.de> wrote: > > One thing I noticed is that writing LLVM assembler code (print() > methods) seems to be horribly slow now (some 4-5 times slower than in > LLVM 2.5). This is a real bummer for me, since Pure's batch compiler > uses those methods to produce output code which then gets fed into > llvmc. >

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

Jeffrey Yasskin wrote: > See Owen's email about docs for the 2.6 release, but it's really not > that hard to keep up with trunk. I recently merged trunk LLVM into > Unladen Swallow, and the changes I needed to make are at > http://code.google.com/p/unladen-swallow/source/detail?r=724. Thanks Jeffrey, that was really very helpful! I have Pure working with both the LLVM 2.6

Óscar Fuentes wrote: > 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). Also, each of LLVM <=2.5, 2.6 and 2.7(svn) provide their own, incompatible llvm::raw_fd_ostream

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

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, The other messages, need to go to stdout as well. Using stderr to output for a switch like --verbose is wrong in my opinion. On 8/14/2013 4:44 PM, Dan Gohman wrote: > Would it be appropriate for lld's other output to go to standard error > instead of standard output, since standard output may be used for YAML > output? > > Dan > > On Wed, Aug 14, 2013 at 12:53

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

Hi Dan, lld takes a -emit-yaml option, which emits the intermediate representation(atoms) in YAML form. By default output goes to stdout, the user can control it by using the -o option too. The way its handled is, similiar to this piece of pseudo-code if (dash_o_option) outputFile = dash_o_option->value() else outputFile = "-" When lld tries to mix things that go to

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

Standard error is what many tools, including clang for example, use for their --verbose output. This is appropriate because it leaves standard output available for regular output data, which the user may wish to capture in a file or a pipe. Dan On Wed, Aug 14, 2013 at 2:48 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Dan, > > The other messages, need to go to

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

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

Would it be appropriate for lld's other output to go to standard error instead of standard output, since standard output may be used for YAML output? Dan On Wed, Aug 14, 2013 at 12:53 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Dan, > > lld takes a -emit-yaml option, which emits the intermediate > representation(atoms) in YAML form. > > By default

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?

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

Hi, When I run the below example, it results in :- hello world LLVM ERROR: IO failure on output stream. Testcase :- #include <llvm/Support/raw_ostream.h> int fn() { std::string errorInfo; llvm::raw_fd_ostream out("-", errorInfo); out << "world\n"; return 0; } int main(int argc, char **argv) { llvm::outs() << "hello\n"; fn();