Displaying 20 results from an estimated 9000 matches similar to: "[LLVMdev] Different behavoir when writing to stdout with 2 raw_fd_ostreams with or w/o redirection"
2012 Nov 29
0
[LLVMdev] Different behavoir when writing to stdout with 2 raw_fd_ostreams with or w/o redirection
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
2012 Nov 29
2
[LLVMdev] Different behavoir when writing to stdout with 2 raw_fd_ostreams with or w/o redirection
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
2012 Nov 29
0
[LLVMdev] Different behavoir when writing to stdout with 2 raw_fd_ostreams with or w/o redirection
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
2015 Jan 23
3
[LLVMdev] Behaviour of outs()?
I was just fixing a bug that was caused by `stdout` being closed
before the runtime has done `fflush(stdout)` [or however this is
implemented in the runtime].
The cause of this seems to be that `outs()` returns a static object
created from `raw_fd_stream(STDOUT_FILENO, true)` - the `true` being
the `shouldClose` parameter.
Surely LLVM is not supposed to close `stdout` as part of its operations?
2015 Jan 23
3
[LLVMdev] Behaviour of outs()?
We've had this argument before. IMO LLVM should not be in the business of
closing stdout, and no code in lib/ should print to stdout because users
may expect output there (-o -).
On Fri, Jan 23, 2015 at 10:20 AM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:
>
> > On 2015-Jan-23, at 09:52, mats petersson <mats at planetcatfish.com> wrote:
> >
> >
2013 Aug 14
3
[LLVMdev] raw_ostream behavior
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
2013 Aug 14
2
[LLVMdev] raw_ostream behavior
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();
2013 Aug 14
5
[LLVMdev] raw_ostream behavior
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
2009 Aug 25
4
[LLVMdev] std::cout << *MyModule does not work anymore
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
2013 Aug 14
0
[LLVMdev] raw_ostream behavior
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
2013 Aug 14
0
[LLVMdev] raw_ostream behavior
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
2013 Aug 14
0
[LLVMdev] raw_ostream behavior
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
2016 Feb 22
2
raw_pwrite_stream to string or stdout?
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
2016 Dec 07
2
Race condition in raw_ostream
> 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
2012 May 04
2
[LLVMdev] MemoryBuffer/raw_ostream hybrid for linker?
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
2016 Dec 07
3
Race condition in raw_ostream
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,
2016 Feb 22
2
raw_pwrite_stream to string or stdout?
TargetMachine::CGFT_AssemblyFile is exactly what I am trying to write out.
Frank
On 02/22/2016 11:06 AM, Rafael Espíndola wrote:
> On 19 February 2016 at 16:16, Frank Winter via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> TargetMachine::addPassesToEmitFile(..)
>> requires as its 2nd argument an raw_pwrite_stream.
>>
>> Is it possible to create such a
2012 May 04
0
[LLVMdev] MemoryBuffer/raw_ostream hybrid for linker?
On May 3, 2012, at 6:10 PM, Nick Kledzik wrote:
> 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.
If this were the only problem, I'd suggest just generalizing
2012 May 07
4
[LLVMdev] [RFC] llvm/include/Support/OutputBuffer.h
For the reasons listed in my 03-May-2012 email, I am proposing a new llvm/Support class for using in writing binary files:
/// OutputBuffer - This interface provides simple way to create an in-memory
/// buffer which when done will be written to a file. During the lifetime of
/// these objects, the content or existence of the specified file is undefined.
/// That is, creating an OutputBuffer
2012 May 08
3
[LLVMdev] [RFC] llvm/include/Support/OutputBuffer.h
On May 8, 2012, at 3:41 PM, Michael Spencer wrote:
> On Mon, May 7, 2012 at 12:56 PM, Nick Kledzik <kledzik at apple.com> wrote:
>> For the reasons listed in my 03-May-2012 email, I am proposing a new
>> llvm/Support class for using in writing binary files:
>>
>> /// OutputBuffer - This interface provides simple way to create an in-memory
>> /// buffer