search for: parsefunctionbodi

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 all, 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 change is in how operand ids are encoded in bitcode files. Rather than use an "absolute

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 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

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

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

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 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

I''m trying to use Canoo WebTest (based on HtmlUnit) to test my webapp after integrating scriptaculous. While my test passed, I get a nice long exception message which barely makes any sense (see below). I found I could get rid of this message by commenting out line 114 of effects.js: 114 this.timeout = setTimeout(this.loop.bind(this), 10); Any idea of what might be causing

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

Hi, I built LLVM + Clang on Mac OS X and ran make check. I get the following result summary: Failing Tests (11): LLVM :: LLVMC/C++/dash-x.cpp LLVM :: LLVMC/C++/hello.cpp LLVM :: LLVMC/C++/just-compile.cpp LLVM :: LLVMC/C++/together.cpp LLVM :: LLVMC/C++/unknown_suffix.unk LLVM :: LLVMC/C/hello.c LLVM :: LLVMC/C/opt-test.c LLVM :: LLVMC/C/sink.c LLVM ::

Thanks to everyone for the quick replies! I spent some time looking into the issue. It turns out that llvm-dis crashes on CLANG-generated bytecode if LLVM is compiled for a 64-bit architecture. The problem disappears when compiling for a 32-bit architecture. Should I file a bug report? Lorenzo On Tue, Oct 26, 2010 at 3:34 AM, Xinfinity <xinfinity_a at yahoo.com> wrote: > > Hi, >

Hi, Probably some of the leaks Valgrind reports are spurious, but the numbers seem to be significant enough to demand some attention: ==10132== LEAK SUMMARY: ==10132== definitely lost: 15,624 bytes in 558 blocks. ==10132== indirectly lost: 44,548 bytes in 1,591 blocks. ==10132== possibly lost: 37,576 bytes in 98 blocks. ==10132== still reachable: 1,336,876 bytes in 1,364 blocks.

Hi all, The C++11 (& C11) compare_exchange functions with explicit memory order allow you to specify two sets of semantics, one for when the exchange actually happens and one for when it fails. Unfortunately, at the moment the LLVM IR "cmpxchg" instruction only has one ordering, which means we get sub-optimal codegen. This probably affects all architectures which use