similar to: [LLVMdev] Status of http://llvm.org/doxygen

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

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

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

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

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

Hi, I am begineer to llvm, implementing a main.cpp from https://github.com/davidar/lljvm/blob/master/backend/main.cpp A) : When I am declaring a command: * PassManager PM* * PM.add(new DataLayout td)* It shows error: > *error: missing template arguments before ‘PM’* * PassManager PM;* ^ >*main_test.cpp:48:2: error: ‘PM’ was not declared in this scope* *

Hi Philip, I also tried that including file: #include "llvm/IR/LegacyPassManager.h" but error remain same. Please help. On Tue, Aug 14, 2018, 2:58 AM Philip Pfaffe <philip.pfaffe at gmail.com> wrote: > Hi Ratnesh, > > the PassManager used in that example has moved into the legacy namespace: > http://llvm.org/doxygen/classllvm_1_1legacy_1_1PassManager.html > >

On Wed, Feb 10, 2016 at 10:50 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> Is this change indeed intended as a visible API change to source code generating references to argument list values? If so, can you point me to a description of how I should change our code? Should I bug someone else about this problem? Should this API change be documented in

I have ran under valgrind memcheck the process using libLLVM-2.9.so (rev.126022) and got several errors: ==24227== Invalid read of size 1 ==24227== at 0x40274C9: memcpy (mc_replace_strmem.c:497) ==24227== by 0x40D5B84: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in

I'm having a problem with MCJIT (in LLVM 3.3 and 3.4), in which it's not resolving symbol mangling in a precompiled bitcode in the same way as old JIT. It's possible that it's just my misunderstanding. Maybe somebody can spot my problem, or identify it as an MCJIT bug. Here's my situation, in a nutshell: * I am assembling IR and JITing in my app. The IR may potentially make

Hi Devang, > llvm-gcc-4-2 development branch is now open for development at > > llvm.org/svn/llvm-project/llvm-gcc-4-2 I noticed the following difference between llvm-gcc and llvm-gcc-4-2 in gcc/llvm-linker-hack.cpp, any idea where it came from? Thanks, Duncan. @@ -28,6 +28,7 @@ #include "llvm/Bitcode/ReaderWriter.h" #include "llvm/CodeGen/ScheduleDAG.h"

I'm trying to link two modules together using the C++ API, one that's a sort of library module and one that's being generated from the source language. If I have something like this: OwningPtr<MemoryBuffer> owning_ptr; if (MemoryBuffer::getFile(StringRef("../hello.bc"), owning_ptr)) std::cout << "error opening file" << std::endl; Module* Lib

I am hitting an LLVM assertion from the llc tool iff the bitcode file is optimized at -O3 level by opt). -O1 and -O2 levels of opt do not cause this assert. LLVM version 3.4svn DEBUG build with assertions. Built Jul 14 2013 (15:39:08). Default target: x86_64-unknown-linux-gnu Host CPU: amdfam10 I have attached the input bc file before -O3 optimization :bzip2.del.bc.tgz I have attached

Hi Danny, On 2007-12-26, at 15:39, Danny wrote: > I've noticed that the BitcodeReader appears to be an internal > module, but the BitstreamReader is public. Should I be using the > BitstreamReader? If so how. The generic BitstreamReader class is public because it's used in other projects, including clang, to serialize data structures other than LLVM IR. The coding of

Hi Hal, I have filed http://llvm.org/bugs/show_bug.cgi?id=16780 -Milind On Fri, Aug 2, 2013 at 9:15 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Milind, > > Have you filed a bug on this? If not, can you please open a bug report (http://llvm.org/bugs)? > > -Hal > > ----- Original Message ----- >> I am hitting an LLVM assertion from the llc tool iff the bitcode

That worked quite well. Thank you. One question as a follow up: is there a nice/standard way of including the pre-made bitcode chunks in with the binaries that are being created which read them? Bascially, I'd like to have the same functionality, but rather than having one or more .bc files running around which need to be read at runtime by an executable, moving that into the code

Milind, Have you filed a bug on this? If not, can you please open a bug report (http://llvm.org/bugs)? -Hal ----- Original Message ----- > I am hitting an LLVM assertion from the llc tool iff the bitcode file > is optimized at -O3 level by opt). -O1 and -O2 levels of opt do not > cause this assert. > > LLVM version 3.4svn > DEBUG build with assertions. > Built Jul 14

Sorry to resurrect an old thread, but I finally got around to testing this approach (round tripping through bitcode in memory) and it works beautifully - and isn't that much slower than cloning. I have noticed however that the copy process isn't thread-safe. The problem is that in Function, there is lazy initialization code for arguments: void CheckLazyArguments() const { if

Hi, I don't see the LLVM bug I filed (http://llvm.org/bugs/show_bug.cgi?id=16780) making any progress. Can someone suggest me whether the bug is in the correct state? -Milind On Fri, Aug 2, 2013 at 1:29 PM, Milind Chabbi <Milind.Chabbi at rice.edu> wrote: > Hi Hal, > > I have filed http://llvm.org/bugs/show_bug.cgi?id=16780 > > -Milind > > On Fri, Aug 2, 2013 at

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