similar to: [LLVMdev] lli tests failing with a segfault on x86-32

These self-host builders all just starting failing. It looks like tablegen is being miscompiled. The first failed builds: (1) http://lab.llvm.org:8011/builders/llvm-gcc-i386-linux-selfhost/builds/208 (2) http://lab.llvm.org:8011/builders/dragonegg-i386-linux/builds/194 (3) http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux/builds/197 The odd thing is that I can't see any suspicious

Hi all I'm currently porting some code to LLVM 2.6 and I stumbled over a weird problem with using JIT compilation in lli on Mac OS X 10.6.2. When running lli without any specific command line options it crashes with a segfault. When I specify "-force-interpreter" or "-march=x86-64", everything works as expected. I can reproduce the problem as follows: // hello.c int

Hi, Anyone knows what's going on with SVN? http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15 http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15 http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh etc. svn: E175012: Connection

Hi Richard, Marco, I noticed that you two are the remaining bot owners using the `getClangBuildFactory` from `ClangBuilder`. All the other bots using that builder have moved to the new `getClangCMakeBuildFactory`, including Windows ones. Given that they do similar functionalities, I'd like to encourage you to move to the new factory, so that we can simplify the builder's code. Thanks!

I have a simple C test file I run a fairly simple Pass on. When I try to run the generated bitcode(after running the pass) with lli all is fine. When I try to compile this down to a actual elf executable I get a segfault. clang -emit-llvm -S test1.c -o test1.bc opt -load ~/llvm/Release+Asserts/lib/LLVMHello.so -hello < test1.bc > test1_pass.bc lli test1_pass.bc # All is fine llc

Dear Renato, Are you still getting the error? I quick spot check on the server shows that most processes are idle and there's 0.5 GB of RAM left. Nothing is jumping out at me as clearly bad (though I am potentially overlooking something). Regards, John Criswell On 6/28/16 10:39 AM, Renato Golin via llvm-dev wrote: > Hi, > > Anyone knows what's going on with SVN? > >

Folks, It seems we got the same issue with Clang alignment as before: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/3025 http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon/builds/485 http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/118 Commits between 231213 and 231255. There are a few issues that could have brought it: *

Renato, thanks for the heads-up. For clang-bpf-build the change should be trivial since we don't use a fancy configuration. I have attached the patch, please apply if appropriate. Thanks. Regards, Marco Leogrande Sent by a carbon-based life form; hence, it may contain repetitions, inaccuracies, logical fallacies and repetitions. On Mon, Oct 31, 2016 at 5:14 AM, Renato Golin

Hi Bill, > As of this writing, we have: > > • several test failures on llvm-gcc self-host: > > http://lab.llvm.org:8011/builders/llvm-gcc-i386-linux-selfhost/builds/25 I can reproduce this here. I'll poke at it this weekend sometime. > • a miscompile in one of the llvm-gcc testers: > > http://lab.llvm.org:8011/builders/llvm-x86_64-linux-checks/builds/55 > >

This is just a reminder to say that we will be branching for the LLVM 3.0 release Friday! 07:00:00 p.m. Friday October 14, 2011 PDT 02:00:00 a.m. Saturday October 15, 2011 GMT Now is the time to look at the buildbots and see what fixes they need: http://lab.llvm.org:8011/console As of this writing, we have: • several test failures on llvm-gcc self-host:

Hi, I've been stuck with this problem for a while now, and my supervisor's starting to think it's a bug in lli, but I thought I'd ask here before going down that route. I have this code, which stores an array in my 'MainClass', and prints out an element of it. Note that the print statement is irrelevant here, it segfaults regardless, and this code has been run with -O2

Hi James, > lli --help says: > > "-enable-eh - Emit DWARF exception handling (default if target supports)" > > But in fact the default on x86-64 linux seems to be disabled, even > though exception handling is supported both for lli and when I use the > JIT as a library. Is this a bug? I can't find where > llvm::DwarfExceptionHandling is being conditionally

Hi all, I have attached the complete test suite. it has different directories for gcc, llvm-gcc , clang and lli-clang. Source code , makefile and run script (contains number of times the program should execute) for each case are available inside each directory. * FOLLOWING ARE THE STATISTICS WHILE USING LLI FOR SINGLE ITERATION*

Hi Toussaint, > llvm-gcc (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2.8) version 2.8 > Low Level Virtual Machine (http://llvm.org/): > llvm version 2.6 version 2.6 You need lli from version 2.8 or later. Ciao, Duncan.

Hi Salomon, please don't forget to reply to the list too (I've CC'd the list). > I don't think my code is doing anything worng... No, it looks fine to me, and the interpreter certainly supports this. That suggests that the value of %str is not being transmitted to the function right. If it is getting the wrong pointer value, that would explain why it barfs. Ciao, Duncan.

Hello, I have a bytecode doing 64 bits division and on Mingw32/x86, lli complains it cannot resolve __udivdi3 when running it. Those symbols are all part of libgcc and all present in lli, but they cannot be found by SearchForAddressOfSymbol (not in any DLL). To workaround that, I explicitely define them in Win32/DynamicLibrary.inc if the current target is Mingw32 (patch attached). Anybody had

Hi, In the process of looking at whether it's reasonable to make ARM use MCJIT by default, I was trying to check that x86-64 uses MCJIT by default (ie, lli doesn't need an explicit -use-mcjit to be passed). However, after instrumenting the constructors for both JIT and MCJIT, either lli doesn't default to using MCJIT on x86-64 or The construction/non-construction of a JIT/MCJIT object

He is probably using the interpreter on a debug build. Evan On Nov 14, 2009, at 1:40 PM, Eric Christopher <echristo at apple.com> wrote: >> >> for -O3 results refer attachment. >> time clang (- >> O0) llvm-gcc(-O0) >> gcc(-O0) >> real >> 0m10.247s

Sorry i really forgot to mention one thing. I downloaded the X86 binaries of llvm+clang and llvm-gcc from llvm download site. i hope that is not a debug build. Prasanth J On Sun, Nov 15, 2009 at 1:22 PM, Prasanth J <j.prasanth.j at gmail.com> wrote: > Hi all, > > LLVM is built without debug enabled. Also i am not forcing lli to use > interpreter mode. so i dont think the

> > for -O3 results refer attachment. > time clang (-O0) llvm-gcc(-O0) gcc(-O0) > real 0m10.247s 0m11.324s 0m10.963s > user 0m2.644s 0m2.478s 0m2.263s