search for: bitcodereaders

Hi, Per my previous post about a patch to run the test suite under valgrind (btw, can I commit it?), I've tracked a few memory leaks in LLVM. I've fixed 4 trivial ones, but there are a few more not-so-trivial remaining. Take a look at two common reports by valgrind: 240 (144 direct, 96 indirect) bytes in 3 blocks are definitely lost in loss record 17 of 20 at 0x4023614: operator

Hi Eli, Thanks for the advice! By delaying processing the "select" until we have resolved other records(like "aggregate " in this case) as you did for "shuffle", the test case passes now. But I wonder if it's an ultimate solution: what if the selector of a "select" is the output of another forward-reference "select" that hasn't been

Hi guys, We have found a bug of BitcodeReader.cpp in processing an LTO bitcode file. As LLVM doesn't emit use-list for LTO bitcode files, many forward references will happen when BitcodeReader processes the bitcode file, and LLVM uses placeholders for those forward references and resolve them later. When parseConstants() reads in a CST_CODE_CE_SELECT record, e.g. select

(cc'ing llvm-dev) Hello Gregory, i just recompiled llvm from scratch, and was able to build the ocaml kaleidoscope bindings. Did you know the llvm's build system already can compile the kaleidoscope tutorials for you? You can run this to build them: make BUILD_EXAMPLES=1 Or just cd into the examples directory in your build directory, and run "make" there. Anyway, I think the

Several people on this list have reported issues with the linker regarding a named StructType instance with the same name in two different modules being resolved into two StructTypes with different names due to StructType:: setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…). Nor do

Hi everyone, sorry to bother you guys. I’m moving a linux application that uses LLVM from version 3.0 to 3.2, and I’m getting a relocation error that I didn’t used to get with the older version of LLVM. I believe that I correctly turned on fPIC, but I’m getting this warning anyway: /usr/bin/ld: /scratch/thirdparty/default/lib/libLLVMBitReader.a(BitcodeReader.o): relocation R_X86_64_PC32

Please ignore, I think this is an issue with an older version of binutils. ________________________________ From: Damien D Neff Sent: 1/4/2013 1:25 PM To: llvmdev at cs.uiuc.edu Subject: Help with linking llvm 3.2 into an .so Hi everyone, sorry to bother you guys. I’m moving a linux application that uses LLVM from version 3.0 to 3.2, and I’m getting a relocation error that I didn’t used to get

Hi Jan, > I've been looking into how to make llvm bitcode files smaller. There is one > simple change that appears to shrink linked bitcode files by about 15%. See > this spreadsheet for some rough data: > > https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E the improvement is wonderful! ... > In any case, the patch is attached if

Hi, I am trying to generate LLVM bytecode using CLANG and I ran into the following problem. If I run clang with the -emit-llvm option and then try to get a textual representation of the output using llvm-dis, the latter crashes because of a failed assertion in BitCodeReader.cpp, mentioning a "Type mismatch in value table" (the exact error message is appended at the end of this email).

Hi, I am using current SVN and in the last week or so, something causing the following assertion failure has changed. void llvm::PATypeHolder::addRef(): Assertion `Ty && "Type Holder has a null type!"' failed. The corresponding stack trace is: #0 0x000000339ec332f5 in raise () from /lib64/libc.so.6 #1 0x000000339ec34b20 in abort () from /lib64/libc.so.6 #2

>> Apparently BitcodeReader.h is only in lib/Bitcode/Reader/ but not in >> include, so a make install does not install it. >I'm not sure what you mean... the header is in include/llvm/Bitcode. >> Is it supposed to be accessible from applications? How exactly? I feel that >> some install rule is missing; after a sudo make install, >> grep -rn BitcodeReader

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

Hi,all I tried to run the generated whole-program bitcode of BIND,but I got some information: 0 lli 0x0000000000feda16 1 lli 0x0000000000fed88f 2 libpthread.so.0 0x0000003df340eee0 3 libc.so.6 0x0000003df28332f5 gsignal + 53 4 libc.so.6 0x0000003df2834b20 abort + 384 5 libc.so.6 0x0000003df282c2fa __assert_fail + 234 6 lli

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

On Fri, May 15, 2015 at 12:02 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015-May-15, at 07:30, Teresa Johnson <tejohnson at google.com> wrote: > > > >>> a. Lazy Debug Metadata Linking: > >>> > >>> The prototype implementation included lazy importing of module-level > >>> metadata during the

Hi, For the first problem, try clang -S -emit-llvm test.c -o test.ll you should get the llvm IR and you don't need to use llvm-dis. Although I have tried your example with the exact commands and source code you posted and it worked just fine for me. I also use clang and LLVM 2.8 compiled from sources. For the second problem, suppress -emit-llvm, since you want the executable, not an object

On Mon, Jul 25, 2011 at 10:50 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Several people on this list have reported issues with the linker regarding a > named StructType instance with the same name in two different modules > being resolved into two StructTypes with different names due to StructType:: > setName(…) collision behavior. Looking at

On Tue, Jul 26, 2011 at 11:01 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jul 26, 2011, at 8:11 AM, Talin wrote: > > >> If that's true, then it means that we're back to the case where every type >> has to be fully defined down to the leaf level. >> >> >> I'm not sure what you mean. LLVM is perfectly fine with opaque structs

Hey there, I'm relatively new to the llvm scene, and so far I'm liking it quite a bit. I'm a bit perplexed as to what llvm-gcc's role is in everything. I've used it to create .bc files for really simple functions and it seems to do quite well at that, but I've been trying to figure out how to take the output from llvm-gcc and actually use it in another program.

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