similar to: [LLVMdev] SVN version fails to compile

On 9/7/2012 12:12 PM, Krzysztof Parzyszek wrote: > On 9/7/2012 7:20 AM, Matthew Curtis wrote: >> >> The attached patch implements one possible solution. It introduces a >> position stack and a couple of directives: >> >> * 'CHECK-PUSH:' pushes the current match position onto the stack. >> * 'CHECK-POP:' pops the top value off of the stack

Hello all, For the hexagon target, we have a couple of tests that are failing due to variations in the order of checked text. In these cases the ordering is not directly relevant to the functionality being tested. For example: ; CHECK: memw(##a) ; CHECK: memw(##b) %0 = load i32* @a, align 4 %1 = load i32* @b, align 4 requires that the compiler emit the memory operations for

all of: ---- // cout << "lsr: " << lsr << "\n"; llvm::MemoryBuffer* mbjit = llvm::MemoryBuffer::getMemBufferCopy (sr); ------ string lsr = sr.str(); // cout << "lsr: " << lsr << "\n";

This segfault occuring only under valgrind, in shell way, and in gdb way i have Invalid bitcode signature simple_scev_dynamic_array: /home/willy/apollo/llvm/include/llvm/Support/ErrorOr.h:258: storage_type *llvm::ErrorOr<llvm::Module *>::getStorage() [T = llvm::Module *]: Assertion `!HasError && "Cannot get value when an error exists!"' failed. Command terminated by

Hello Willy, Here is the dump from one of my bitcode files: 0000000 42 43 c0 de 21 0c 00 00 25 05 00 00 0b 82 20 00 As expected, 0x42 (= B), 0x43 (= C), xc0 and 0xde are in correct order. In your case, the first byte is read as 37 (= 0x25). I wonder why? When you check the bytes yourself, you get expected results. When the same bytes are read from Stream object, you get a different result (maybe

Hi all, I'm trying to add pre-compiled object cache to my run-time. I've implemented the object cache as follow: class EngineObjectCache : public llvm::ObjectCache { private: std::unordered_map<std::string, std::unique_ptr<llvm::MemoryBuffer>> CachedObjs; public: virtual void notifyObjectCompiled(const llvm::Module *M, llvm::MemoryBufferRef Obj) { auto id =

I'm getting an error when trying to build llvm 2.2's tblgen: llvm[2]: Linking Release executable tblgen (without symbols) /usr/bin/ld: Undefined symbols: llvm::MemoryBuffer::getFileOrSTDIN(char const*, unsigned int, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*, long long) llvm::cl::ParseCommandLineOptions(int, char**, char const*) It's

Hi,all Recently,I write some code to implement the following funtions: I make use the codes of "llvm-dis" to disassemble the bitcode file and do some change on it,after that ,"my llvm-as" assembles the changed file to generate a bitcode file. But I got a "corrupted double-linked list" error when "my llvm-as" works,however,when I do nothing on the

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

Hi, LLVM community, I found an issue in my using scenario. We deliberately parse a bitcode file twice. It contains a named struct type. eg. %struct.cmd = type { float, float, float, float, float, i32 }. In the second module->dump, %struct.cmd becomes %struct.cmd0. my code is simplified like this. int main() { llvm::LLVMContext &llvmCtx = llvm::getGlobalContext(); string ErrMsg;

Hi, I'm using LLVM 2.4 (but llvm-gcc 2.2) on Ubuntu 8.10 (Intrepid Ibex) for a small part-time project combining Witty (http://www.webtoolkit.eu) and the ExecutionEngine in LLVM. (This is my second week with any of these so I still lack a lot of basic knowledge.) Sometimes I want to call a function returing a struct (in this case std::string), thus hasStructRetAttr() is true for the Function

I have been working towards this on D63859. My current route was to add an optional callback to MemoryBuffer::getFileOrSTDIN which will be executed if stdin has not been redirected. James and I were talking over there and are maybe deciding that this might not be the best solution. The alternative in my mind is that the tools which want this behavior could do so by explicitly testing if

When I enabled this option I am getting errors, see below. Is there any way to fix this? There should be an option to have most of the code in shared library. Yuri --- error log using gcc-4.5.0 on 4 cpus with configure options: --enable-assertions --enable-optimized --enable-shared --prefix=/usr/local/llvm --- llvm[2]: Compiling llc.cpp for Release build gmake[2]: Entering directory

Chris Lattner <clattner at apple.com> writes: > On Nov 16, 2016, at 9:46 PM, Justin Bogner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> 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

Hi all, I am trying to load a profile information (llvmprof.out) which has been separately created, to get the execution count of each basic block and use it to estimate the execution count of machine basic blocks for getting how many times any instruction gets executed, for ARM specifically. The error on running the code comes as: clang: PassManager.cpp:601: void

--enable-shared was _created_ in 2.7. If you were passing it in 2.6 or earlier, it wasn't doing what you expected. I just tried it again on trunk (not 2.7) on OSX 10.5, and it works. What platform are you on? Does it work with another version of gcc? On Tue, Apr 27, 2010 at 4:06 PM, Yuri <yuri at tsoft.com> wrote: > > When I enabled this option I am getting errors, see below.

On Jul 24, 2011, at 6:31 PM, David Blaikie wrote: >>> This keeps things simple & seems to be "good enough" to me, but we >>> could perhaps do better (at the very least, again, if we did do >>> better, we could go back & remove TwineString & again fix all the >>> places that fail to compile with whatever new hotness we invent) >>

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

Hello, I having a weird problem while writing a bytecode module to a string, and after read/parse it for unsing on a jit. I write a pass to export function to module, and put this module inside a global variable. I use WriteBitcodeToFile for this. For debuging, after this write, I try to load the exported module with parseBitcodeFile. This two step works. After, while the compiled program is

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