search for: raw_ostreams

I'm trying to link a program with LLVM on Linux. I've managed to take out the test files from 'llvm-config --libs' but now it's getting errors with missing symbols. The same program successfully links with the same version of LLVM (3.8) on Windows, so it's not a problem with the code per se, it's some kind of configuration issue. Any ideas? g++ -std=c++11

Tried that just now, same result. On Fri, Mar 25, 2016 at 6:58 AM, Snehasish Kumar <kumar.snehasish at gmail.com> wrote: > Hi Russel, > > Can you try compiling aklo.o using -fno-rtti prior to linking? > > On Thu, Mar 24, 2016 at 11:44 PM, Russell Wallace via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I'm trying to link a program with LLVM on Linux.

Hi I come across the following exception when I use the llvm-dwarfdump -debug-info target_binary: llvm-dwarfdump: /home/linux/llvm-7/llvm/lib/MC/MCRegisterInfo.cpp:87: int llvm::MCRegisterInfo::getLLVMRegNum(unsigned int, bool) const: Assertion `I != M+Size && I->FromReg == RegNum && "Invalid RegNum"' failed. Stack dump: 0. Program arguments:

Hi Russel, Can you try compiling aklo.o using -fno-rtti prior to linking? On Thu, Mar 24, 2016 at 11:44 PM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I'm trying to link a program with LLVM on Linux. I've managed to take out > the test files from 'llvm-config --libs' but now it's getting errors with > missing symbols. The same program

Yeah, seems to. a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv U _ZN4llvm4outsEv U _ZN4llvm4outsEv 0000000000000000 b _ZGVZN4llvm4outsEvE1S 0000000000000000 T _ZN4llvm4outsEv 0000000000000000 r _ZZN4llvm4outsEvE19__PRETTY_FUNCTION__ 0000000000000000 b _ZZN4llvm4outsEvE1S U _ZN4llvm4outsEv I can try building

Since the log tells you that llvm::outs() is not found, and since it is supposed to be found in libLLVMSupport.a, you can try: $ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv ... 0000000000002070 T __ZN4llvm4outsEv ... The output should have the symbol defined. -- Mehdi > On Mar 25, 2016, at 12:18 AM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote:

Hi Dave I am not going to access any hardware. I am using clang to analysis the ARM binaries. The binary is 483.xalancbmk in CPU SPEC2006. When I use the optimization O0, no crash will occur. The crash occurs when I set optimization level as O1,O2,O3 and Os. If I have to recompile and rerun the tests. What version of llvm is suggested. It would be better if anyone could provide the patch on this

Looking again at your link line, I think static library has to appear after their uses. So try to put the .o before the list of library. -- Mehdi > On Mar 25, 2016, at 12:41 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > > Yeah, seems to. > > a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv > U

I've been using the nifty: DEBUG(errs() << "Here is the state of things:\n"); style of optional logging, but ran into an issue where I want to dump a table of information. The problem is getting the columns to line up, since the raw_ostream methods write numbers as variable length. I've worked up a patch that adds two new methods to raw_ostream: /// write_hex -

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 Dave Sorry, I meant the hardware you're using to compile LLVM - you mentioned it took you a long time to rebuild it so it would be hard for you to write/experiment on tests. ============================= Compiling LLVM doesn't take me too much time(less than 2 hours). The hardware is good enough and I am using interl E5 CPU. What I mean is that it took me a long time to analysis the

+update diff 2015-05-02 7:38 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > I outlined (is that the right > word?) raw_char_ostream::grow, raw_char_ostream::write (both) into > raw_ostream.cpp with less than 10% difference in performance. > > Profiling reveals that the real culprit is the code line > > OS.reserve(OS.size() + 64); > > called from

On May 18, 2012, at 11:50 AM, Nick Kledzik <kledzik at apple.com> wrote: > I've been using the nifty: > DEBUG(errs() << "Here is the state of things:\n"); > style of optional logging, but ran into an issue where I want to dump a table of information. The problem is getting the columns to line up, since the raw_ostream methods write numbers as variable length.

...lieve "the is racy” is an appropriate qualification, “buffered > raw_ostream are not providing a thread-safe API" seems more accurate to me. I agree. Acquiring a lock on each write to a buffered raw_ostream is too expensive. You can always explicitly use std::mutex if you have shared raw_ostreams. > > > Of course, one might wonder why someone would need to output to a stream > from multiple threads at the same time. > > > > But imagine someone might get logs to dbgs() or errs() running the > backend for a target in multiple threads. > > These are unbuffere...

...d for the operator<<(). It is very possible I missed something, but you’ll need to help me figuring out where the race is. — Mehdi > > > I agree. Acquiring a lock on each write to a buffered raw_ostream is too expensive. You can always explicitly use std::mutex if you have shared raw_ostreams. > > Of course you can do it in your code. But there's a lot of "dbgs() <<" in the backends. > And e.g. if you want to have multithread invocation of a debug version of the lib, but without changing the backend... you might get the race condition. > > That's...

This code from raw_ostream.h is really racy: raw_ostream &operator<<(StringRef Str) { // Inline fast path, particularly for strings with a known length. size_t Size = Str.size(); // Make sure we can use the fast path. if (Size > (size_t)(OutBufEnd - OutBufCur)) return write(Str.data(), Size); if (Size) { memcpy(OutBufCur, Str.data(), Size);

On Friday 18 December 2009 13:56, David Greene wrote: > On Friday 18 December 2009 13:53, David Greene wrote: > > > > + void releaseStream() { > > > > + // Delete the stream if needed. Otherwise, transfer the buffer > > > > + // settings from this raw_ostream back to the underlying > > > > stream. + if (!TheStream) > > >

On Friday 18 December 2009 17:22, David Greene wrote: > On Friday 18 December 2009 13:56, David Greene wrote: > > On Friday 18 December 2009 13:53, David Greene wrote: > > > > > + void releaseStream() { > > > > > + // Delete the stream if needed. Otherwise, transfer the > > > > > buffer + // settings from this raw_ostream back to

Could you dig into why: + raw_ostream &write(unsigned char C) override { + grow(1); + *OutBufCur++ = C; + return *this; + } Is 3 times as fast as raw_svector_ostream? I don't see a good reason why that should be any faster than: raw_ostream &operator<<(char C) { if (OutBufCur >= OutBufEnd) return write(C); *OutBufCur++ = C; return *this; }

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