similar to: [LLVMdev] Change in I/O Streams

Hi all, With the newest patches to LLVM, there should be no reason for having "#include <iostream>" in any library source code file, except for lib/ Support/Streams.cpp. Please use the following instead: OLD NEW --- --- std::ostream llvm::OStream std::istream llvm::IStream std::cerr llvm::cerr std::cerr llvm::cout

Bill Wendling wrote: > Hi all, > > With the newest patches to LLVM, there should be no reason for having > "#include <iostream>" in any library source code file, except for lib/ > Support/Streams.cpp. Please use the following instead: > > OLD NEW > --- --- > std::ostream llvm::OStream > std::istream

Bill Wendling wrote: It seems that when compiling Debug versions of LLVM, we use stream manipulators (like std::hex) on the new LLVM streams, and doing so causes a compiler error when compiling LLVM with GCC 3.4.0. I commited a fix to work around the problem, but it seems to me it would be better if LLVM streams could support common stream manipulators. First, has anyone else experienced the

On Thu, 7 Dec 2006, Bill Wendling wrote: > With the newest patches to LLVM, there should be no reason for having > "#include <iostream>" in any library source code file, except for lib/ > Support/Streams.cpp. Please use the following instead: > > OLD NEW > --- --- > std::ostream llvm::OStream > std::istream

The solution (provided in Microsoft's documentation) is to add: #include <cstdio> #include <io.h> #include <fcntl.h> and run: int result = _setmode( _fileno(stdin), _O_BINARY ); if( result == -1 ) { std::cerr<<"Cannot set input mode to binary."<<std::endl; return 1; } result = _setmode( _fileno(stdout), _O_BINARY ); if( result == -1 ) {

On Tue, 23 May 2006, Michael Smith wrote: > The solution (provided in Microsoft's documentation) is to add: > #include <cstdio> > #include <io.h> > #include <fcntl.h> > and run: > int result = _setmode( _fileno(stdin), _O_BINARY ); > if( result == -1 ) > { std::cerr<<"Cannot set input mode to binary."<<std::endl; return 1; >

Nothing really needs to be done on Unix, because to my knowledge Unix doesn't differentiate between text and binary on stdin/stdout. ~Michael -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Reid Spencer Sent: Tuesday, May 23, 2006 11:25 AM To: LLVM Developers Mailing List Subject: RE: [LLVMdev] Binary output to cout on

On Feb 27, 2009, at 1:47 AM, Jay Foad wrote: > Hi, > > I noticed this code in lib/Transforms/Scalar/InstructionCombining.cpp: > > cerr << "WARNING: While resolving call to function '" > << Callee->getName() << "' arguments were dropped!\n"; > > If you're using LLVM as a static compiler, this warning is a

On Feb 27, 2009, at 10:37 AM, Evan Cheng wrote: > > On Feb 27, 2009, at 1:47 AM, Jay Foad wrote: > >> Hi, >> >> I noticed this code in lib/Transforms/Scalar/ >> InstructionCombining.cpp: >> >> cerr << "WARNING: While resolving call to function '" >> << Callee->getName() << "' arguments

Hi, I noticed this code in lib/Transforms/Scalar/InstructionCombining.cpp: cerr << "WARNING: While resolving call to function '" << Callee->getName() << "' arguments were dropped!\n"; If you're using LLVM as a static compiler, this warning is a bit incongruous, because it's not formatted in the same way as warnings from

Hello list, I learned that under LLVM, #including of <iostream> is forbidden. Instead LLVM provides llvm::raw_ostream(for std::cout, std::cerr) and llvm::MemoryBuffer(for input stream). And using of llvm::raw_ostream is pretty easy but for me learning of how to use llvm::MemoryBuffer is pretty much difficult. I found a good sample code; utils/yaml2obj/yaml2obj.cpp. The function, main() in

Is this for user prompts, or just reading data from stdin? You can use MemoryBuffer::getSTDIN to read the contents of stdin into a memory buffer. Then you can get the data pointer and size and read it in. As far as I know, there is not a good way to implement user prompts with the LLVM APIs. On Mon, Jan 14, 2013 at 4:57 AM, Journeyer J. Joh <oosaprogrammer at gmail.com>wrote: >

Hi Justin Holewinski, >> As far as I know, there is not a good way to implement user prompts with the LLVM APIs. This info helps me a lot. I tried to do a thing that is not possible. Thank you very much. Sincerely Journeyer 2013/1/15 Justin Holewinski <justin.holewinski at gmail.com>: > Is this for user prompts, or just reading data from stdin? You can use >

And for this kind of question I think I would better hold in. There would be more important issue worth on this list. For this reason I am sorry. Sincerely Journeyer 2013/1/15 Journeyer J. Joh <oosaprogrammer at gmail.com>: > Hi Justin Holewinski, > >>> As far as I know, there is not a good way to implement user prompts with the LLVM APIs. > > This info helps me a

Hello, lately, I have been thinking about how to resolve the problem with that the program size increases enormously when including <iostream> when compiling with libstdc++. In this library, in <iostream> there is a static object __ioinit initialized like so: ... // For construction of filebuffers for cout, cin, cerr, clog et. al. static ios_base::Init __ioinit; ... This

Hi Dave, > We ran into a similar problem in our custom code here. To work around > it I modified Debug.h like this: > > #ifdef NDEBUG > static llvm::OStream NullStream(0); > #define DOUT llvm::NullStream > #else > #define DOUT llvm::getErrorOutputStream(DEBUG_TYPE) > #endif > I thought about doing this, but there's the potential for naming conflicts that

On 11/30/06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 11/30/06, Andrew Lenharth <andrewl at lenharth.org> wrote: > > The llvm_ostreams, which you take the address of go out of scope very > > quickly, and are only stored by address in the bytecode writer, thus > > the writers have a pointer to a stack allocated object they are to > > write

Actually, take a look at the current TOT for llvm-gcc4. Jim & I put a patch in there yesterday that should make things work with llvm_ostreams. -bw On 11/30/06, Bill Wendling <isanbard at gmail.com> wrote: > On 11/30/06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > On 11/30/06, Andrew Lenharth <andrewl at lenharth.org> wrote: > > > The

llvm-gcc is producing segmentation fault when running with -emit-llvm. Running cc1 in valgind produces the warning: ==12768== at 0x8D042C: llvm::llvm_ostream& llvm::llvm_ostream::operator<< <llvm::Module>(llvm::Module const&) (Streams.h:41) ==12768== by 0x8D0464: llvm::PrintModulePass::runOnModule(llvm::Module&) (PrintModulePass.h:41) ==12768== by 0xED6EB9:

On Nov 7, 2007, at 6:10 PM, Antony Blakey wrote: > Hi, > I'm experimenting with using LLVM to generate dynamic FFI bridges > in VisualWorks Smalltalk. LLVM is an amazing thing! I'm going from > dynamically generated assembler source to machine code, and I have > that all working, copied from the llc tool and the JIT example. I > have two questions: > > 1. What