similar to: [LLVMdev] Converting raw_ostream to std::ostream

Hi all, I need to use the printing methods from a third-party library. The problem is those methods use std::cout but the use of std::ostream methods seems to be disabled in latest versions of LLVM. I'm aware of raw_os_ostream (http://llvm.org/doxygen/classllvm_1_1raw__os__ostream.html) which takes a std::ostream as input. E.g., I could do something like: #include

Hi Jorge, > I need to use the printing methods from a third-party library. The > problem is those methods use std::cout but the use of std::ostream > methods seems to be disabled in latest versions of LLVM. > > I'm aware of raw_os_ostream > (http://llvm.org/doxygen/classllvm_1_1raw__os__ostream.html) which > takes a std::ostream as input. E.g., I could do something like:

Previously I had asked how to write then read back IR to/from a file. The write code looked like: LLVMContext ctx; SMDiagnostic diag; Module *m = ParseIRFile( "my_file", diag, ctx ); However, the code I'm trying to retrofit LLVM IR into passes me just a std::ostream&. How can I read IR from a std::ostream? I figured out how to use raw_os_ostream to adapt a

Daniel Dunbar <daniel at zuster.org> writes: [snip] >> Is all this an unintended change or an intentional one, and if the >> later, could you direct me to something that explains what we gain on >> exchange of this restriction? > > Intentional. std::ostream has long been deprecated in LLVM, each > release has increased the degree of deprecation. The coding

Hi, I'm writing some code that prints to std::ostream. However, it seems that all of the LLVM objects can only print to llvm::raw_ostream, so I can't do this: void write(std::ostream &out) { ... for (BasicBlock::iterator i = block->begin(), e = block->end(); i ! = e; ++i) { Instruction *instruction = i; out << *instruction << std::endl;

On Mon, Aug 24, 2009 at 5:40 PM, Óscar Fuentes<ofv at wanadoo.es> wrote: > 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. Correct. std::ostream has been purged from LLVM; the only

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 Apr 1, 2010, at 3:52 PM, Trevor Harmon wrote: > Hi, > > I'm writing some code that prints to std::ostream. However, it seems > that all of the LLVM objects can only print to llvm::raw_ostream, so I > can't do this: > > void write(std::ostream &out) { > ... > for (BasicBlock::iterator i = block->begin(), e = block->end(); i ! > = e;

The high-level answer is that library code shouldn't hardcode output paths, including "-" and including using llvm::outs(). Library code should (in general) instead accept an ostream in its API and write to wherever it is being asked to write. If this is followed, the only place in any program using llvm::outs() is code which is not part of a "library" -- i.e. it is the

Hi Craig, I updated from the trunk some minutes ago, and thus got the "explicit". PrintReg constructor. When I do not include raw_ostream.h after including Debug.h in the backend cpp files, I now get compilation errors, not only when trying to print floats but also in other places. For example, for the code bool ADRESRegisterInfo::hasReservedCallFrame(const MachineFunction &MF)

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

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();

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

When I try to print out a instruction by the following way, I am getting the error message below. Anyone knows what's the problem? Instruction* inst; ... inst-print(cerr); testbuild.cpp:178: error: no matching function for call to 'llvm::Instruction::print(llvm::OStream&)' /x/pchsu/llvm/llvm-2.4/include/llvm/Value.h:83: note: candidates are: void

Hi, that solved my problem on trunk as well, thanks. Strange that you have to include this though. Bjorn On 27 Nov 2012, at 00:00, Daniel Prokesch <daniel.prokesch at gmail.com> wrote: > Hi, > > I accidentally stumbled upon your post. > I observed similar behaviour whenever I did not include > > #include "llvm/Support/Debug.h" > #include

Rafael Avila de Espindola <rafael.espindola at gmail.com> writes: >> On Mar 22, 2014, at 1:31, Justin Bogner <mail at justinbogner.com> wrote: >> Also, the header includes a "clang::io" namespace with some operations >> for reading and writing little endian files. Should these be directly >> renamed to "llvm::io", or would something like

Can you try making the constructor "explicit" for PrintReg in include/llvm/Target/TargetRegisterInfo.h. I think you were getting an implicit conversion there which should probably be fixed anyway. On Mon, Nov 26, 2012 at 11:47 PM, Bjorn De Sutter < bjorn.desutter at elis.ugent.be> wrote: > Hi, > > that solved my problem on trunk as well, thanks. Strange that you have to

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

To get Tutorial 1 to compile, I had to cast cout as a raw_osstream, as in: PM.add(createPrintModulePass(&llvm::cout)); ----> PM.add(createPrintModulePass((raw_ostream*)&llvm::cout)); I was getting the following error: $ c++ -g tut1.cpp `llvm-config --cxxflags --ldflags --libs core` -o tut1 tut1.cpp: In function ‘int main(int, char**)’: tut1.cpp:19: error: cannot convert

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