similar to: [LLVMdev] lib/Support/MemoryBuffer.cpp: wrong assert(BufEnd[0] == 0 && "Buffer is not null terminated!");

MemoryBuffer requires that its buffer be NULL terminated. This is handy for some users, but it is a hard requirement for some cases. For example, currently I get the following valgrind error when doing LTO and fetching an archive member: at 0x6DAC36E: llvm::MemoryBuffer::init(char const*, char const*) (MemoryBuffer.cpp:50) Address 0x5fecea0 is 0 bytes after a block of size 464 alloc'd

On Thu, Sep 24, 2009 at 2:32 PM, Chris Lattner <clattner at apple.com> wrote: > > On Sep 24, 2009, at 1:23 PM, OvermindDL1 wrote: > >> I was writing something using MemoryBuffer, and while looking through >> its code I came across line 59: >> assert(BufEnd[0] == 0 && "Buffer is not null terminated!"); >> I am curious if the MemoryBuffer

I was writing something using MemoryBuffer, and while looking through its code I came across line 59: assert(BufEnd[0] == 0 && "Buffer is not null terminated!"); I am curious if the MemoryBuffer only supports non-binary, non-null embedded files, or if it supports binary as well. I do not see anything inherently not expecting binary files except for that one line, so I am

On Thu, Sep 24, 2009 at 4:26 PM, Gordon Henriksen <gordonhenriksen at me.com> wrote: > NUL-termination is an optimization, in particular for clang's parser, > where it's cheaper to check for '\0' to signal EOF than it is to > compare pointers. Its presence doesn't move the end iterator (just > makes it dereference-able) and in no way impacts your ability to

When I run the following example, I get this error: LLVM ERROR: Invalid instruction Replacing C++ with trivial hello world makes it work. rev.147747 Yuri --- example (please save as .sh file) --- #!/bin/sh cat >f.C <<_END_ extern void xthrowingx(); extern void xcatchingx_char(char c); extern void xcatchingx_int(int i); extern void xcatchingx_all(); void f() { try {

Forwarding the patch to commits so that it doesn't get lost. Yuri -------- Original Message -------- From: - Fri Jun 03 12:15:47 2011 X-Mozilla-Status: 0011 X-Mozilla-Status2: 10000000 Return-Path: <llvmdev-bounces at cs.uiuc.edu> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail1.rawbw.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=7.0

In MemoryBuffer::init, we have an assert that reads the memory at `BufEnd`, which is one past the end of some memory region: from lib/Support/MemoryBuffer.cpp:45: > void MemoryBuffer::init(const char *BufStart, const char *BufEnd, > bool RequiresNullTerminator) { > assert((!RequiresNullTerminator || BufEnd[0] == 0) && > "Buffer is not

I'm using the latest llvm/clang 2.8 releases and am getting EXC_BAD_ACCESS crashes in ContentCache::getBuffer. This happens when I'm printing out errors from a compilation run and iterating over TextDiagnosticBuffer returned errors. When checking the errors, I construct a FullSourceLoc and do: int LineNum = SourceLoc.getInstantiationLineNumber(); int ColNum =

I checked recent revisions 138624 and 138620 and both produce this log with gcc-4.6.0 on FreeBSD-8.2-STABLE amd64: gmake[2]: Entering directory `/usr/home/yuri/llvm-svn/llvm-objects/lib/CodeGen' llvm[2]: Compiling LLVMTargetMachine.cpp for Release build /usr/home/yuri/llvm-svn/llvm/lib/CodeGen/LLVMTargetMachine.cpp:253:3: error: ‘AsmStreamer’ does not name a type

Yuri, on which host? 2011/8/17 Yuri <yuri at rawbw.com>: > In r134967 it still worked, and in r137742 it now doesn't. > I used such flags: --enable-assertions --enable-shared --enable-libffi > --enable-debug-runtime --enable-debug-symbols --disable-optimized > > Before build would create directory tools/llvm-shlib under the build > tree. Now it is missing. In my

On Apr 17, 2013, at 7:26 PM, Yuri <yuri at rawbw.com> wrote: > On 10/02/2012 13:01, Duncan Sands wrote: >> >> I think Chris is the right person to look at this, hopefully he will. > > Now 5 months passed. I updated the patch for this current revision. > Can anybody review this and check in please? > > http://llvm.org/bugs/show_bug.cgi?id=13163 >

I noticed that this command returns NO through ssh: > $ ssh user at host "if [ -t 1 ]; then echo YES; else echo NO; fi" > NO and YES when run locally (of course): > $ if [ -t 1 ]; then echo YES; else echo NO; fi > YES I can't find any command line option related to running command remotely in terminal. I think users intuitively expect commands to be run in

-Wenum-compare is buggy / bogus. We should turn this warning off in our build scripts if possible. On Tue, Jun 26, 2012 at 5:15 PM, Yuri <yuri at rawbw.com> wrote: > I just switched gcc from 4.6.2 to 4.7.1 and see the massive amount of > warnings, see few examples below. > They mostly didn't exist with gcc-4.6.2. > > rev.159224 > > Yuri > > >

On Thu, Sep 24, 2009 at 5:38 PM, Gordon Henriksen <gordonhenriksen at me.com> wrote: > On 2009-09-24, at 18:56, OvermindDL1 wrote: > > Out of curiosity, what code in Clang is optimized by doing a > pointer derefence then compare to 0, rather then just comparing two > points directly? Does not seem that efficient when laid out like that, > which is why I am curious what

I've built clang+llvm in an object directory successfully, and I'm sure others have. I'd guess the problem is the symlink, so I'd give it a shot without it. Reid On Thu, Jun 10, 2010 at 7:43 AM, Diego Iastrubni <diegoiast at gmail.com> wrote: > can you tell what commands exactly did you use? > > What I usually do is: > > svn co llvm... > mkdir

----- Original Message ---- > From: Chris Lattner <clattner at apple.com> > To: Yuri <yuri at rawbw.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Sun, February 20, 2011 3:26:35 AM > Subject: Re: [LLVMdev] Announcing: LLVM 2.9 Tentative Release Schedule > > > On Feb 19, 2011, at 8:05 PM, Yuri wrote: > > > On 02/19/2011 14:52, Yuri wrote: > >>

I mad the change, and still have the problem. I investigate more the source code of llvm. First, I change isRawBitcode function to print the content of the parameter like this: original: http://llvm.org/docs/doxygen/html/ReaderWriter_8h_source.html#l00081 inline bool isRawBitcode(const unsigned char *BufPtr, const unsigned char *BufEnd) { // These bytes sort

Have you found http://llvm.org/docs/DebuggingJITedCode.html? The JIT already has support for something like this for gdb's benefit. Perftools and valgrind just don't know how to find it yet. On Sat, Jun 19, 2010 at 2:03 PM, Yuri <yuri at rawbw.com> wrote: > This new option (--jit-emit-debug-function-range) will allow to output > function information for memory ranges that

can you tell what commands exactly did you use? What I usually do is: svn co llvm... mkdir llvm/tools/clang svn co llvm/tools/clang mkdir cmake-build cd cmake-build cmake ../ make Try something similar by running "../configure", it should work. On Thu, Jun 10, 2010 at 11:23 AM, Yuri <yuri at rawbw.com> wrote: > I did these steps: > * checked out llvm trunk, and clang

On Thu, Feb 20, 2014 at 1:58 PM, Yuri <yuri at rawbw.com> wrote: > On 02/18/2014 00:44, 杨勇勇 wrote: > >> I ported llvm backend and lldb recently. Both tools can basically work. >> lldb is able to debug programs in asm style and frame unwinding is OK. >> >> But "frame variable XX" does not work because lldb is not able to >> determine >> the