similar to: [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: > > > >

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

In several places, for example in JITDebugRegisterer::MakeELF, stream is opened and the error is ignored. When the error is actually returned by open There are two solutions (assuming there are no exceptions). 1. check error string after every raw_fd_stream::raw_fd_stream, fix all the places where the check is missing 2. make raw_fd_stream::raw_fd_stream exit I suggest the second should be

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! just a minor thing: FormattedStream.h is in llvm/Support/FormattedStream.h and not in llvm/CodeGen/FormattedStream.h, therefore the comment at the beginning of the file has to be changed. -Jochen

-------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041025/d290c6e0/attachment.txt>

Hmm, I guess I need a sys::Math::getRandom() function that uses a "good" random number generator on the given platform. I'll make a note of this and tuck it away for future implementation. Reid. Chris Lattner wrote: > On Tue, 28 Sep 2004, Paolo Invernizzi wrote: > > >>The next major problem is that VC has only >> >>int rand(void) >>void srand(

Building on OS X 10.7.1 with the standard toolchain, I have seen the following linker warnings going back a number of versions in trunk whenever I build an executable linked with LLVM: ld: warning: direct access in llvm::fouts() to global weak symbol llvm::formatted_raw_ostream::~formatted_raw_ostream() means the weak symbol cannot be overridden at runtime. This was likely caused by

Morten Ofstad wrote: >> Hi, >> >> There's no HAVE_RAND48 symbol provided by autoconf. You'll have to >> add the appropriate check to autoconf/configure.ac before we can take >> this patch. I installed autoconf with cygwin now and I think I've managed to do this right now -- there are some strange problems with running the AutoRegen.sh script, so I

On Wed, May 4, 2016 at 3:10 PM, Stanislav Manilov < stanislav.manilov at gmail.com> wrote: > As in "look at the source of clang" or as in "look at the -S -emit-llvm" > output? If you mean the former, then would that be easy for someone who > hasn't seen the clang source before? > Generally the latter - then potentially set some breakpoints & look at

> Hi, > > There's no HAVE_RAND48 symbol provided by autoconf. You'll have to add > the appropriate check to autoconf/configure.ac before we can take this > patch. Sorry I forgot to mention I didn't make any changes to the configure script. The problem is that I can't test these things since I'm not on a Unix platform, and I'm not even using the

Hi, I was trying to do a source to source transformation in llvm from c++11 more basic c++ (to transform away auto etc.) using llvm3.1. I generate llvm bitcode using "clang++ -emit-llvm ...", but executing llc -march=cpp throws /home/broes/software/llvm/lib/Target/CppBackend/CPPBackend.cpp:493: void {anonymous}::CppWriter::printAttributes(const llvm::AttrListPtr&, const

Hi everyone, We are using the llvm2cpp feature of LLVM in the VMKit project and there are some issues that I would like to point out. I made a tiny reproducible example here, to be clear: echo "int main() { return 0; };" > test.c && clang test.c -emit-llvm -c -o - | llc -march=cpp -cppgen=function -cppfor=main -o - This command is supposed to generate the C++ code to

Hello, I was trying to compile a simple program with the CppBackend like so: $ clang str_arg.c -emit-llvm -S $ llc -march=cpp str_arg.ll It produces a file `str_arg.cpp` as expected, however it doesn't seem that the resulting file is correct. For once, it includes `<llvm/Analysis/Verifier.h>` which seems to have been moved to `llvm/IR/Verifier.h` as far back as 2013. My question is

The usual advice I provide people is "see what Clang does with an equivalent C construct" On Wed, May 4, 2016 at 12:18 PM, Stanislav Manilov < stanislav.manilov at gmail.com> wrote: > Hi, > > There is another benefit to keeping the CppBackend: it's great for > learning how to use the IR and the C++ API in particular, as can be seen > from this SO Q&A: >

+1 On Wed, May 4, 2016 at 3:10 AM, Filipe Cabecinhas via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On Wed, May 4, 2016 at 9:35 AM, Ronan KERYELL via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > >>>>>> On Tue, 3 May 2016 16:36:01 -0400, Rafael Espíndola via llvm-dev < > llvm-dev at lists.llvm.org> said: > > > >

On Wed, 29 Sep 2004, Reid Spencer wrote: > > On Tue, 28 Sep 2004, Paolo Invernizzi wrote: > >>The next major problem is that VC has only > >> > >>int rand(void) > >>void srand( int seed ) > >> > >>So I donno how to compile the > >>ExecutionEngine/Interpreter/ExternalFunctions.cpp that refers to the > >>drand48 srand48

Oh, well... as usually the answer appears to be pretty obvious. 99% of the time is spent inside the plain write. -print-after-all prints into llvm::errs(), which is an *unbuffered* raw_fd_stream. And -git-commit-after-all opens a *buffered* raw_fd_stream. As soon as I hacked -print-after-all to use a buffered stream to stderr performance went up to the normal expected values: ] time bin/opt

Hey all, Quick query on out of tree target support - at present I can drop a folder Foo into <llvm>/lib/Target/Foo and use the CMake option LLVM_EXPERIMENTAL_TARGETS_TO_BUILD to pick up my target. The issue is that I still need to patch the one LLVMBuild.txt file in <llvm>/lib/Target with; |iff --git a/lib/Target/LLVMBuild.txt b/lib/Target/LLVMBuild.txt index 4112046..6e42cbe