similar to: What is the correct way to cross-compile LLVM and run the (in-tree) tests on a target board?

It is $target dependent. I’m curious what makes you think it is $host dependent. Thanks, Taewook On 3/3/17, 5:10 PM, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote: On 3/3/17 12:23 PM, Taewook Oh wrote: > Thanks Jon. Actually I tried “x86_64-linux”, but it makes the test “Unsupported” from my linux machine, and it was because my test is under

I'm not sure that test have ever been run through LIT. It was tested on Android, but I don't have LIT tweaked for libc++abi the same way I do for libc++, so it was built outside of LIT and run manually. On Oct 27, 2014 11:41 AM, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote: > > > On 10/27/14 11:39 AM, Renato Golin wrote: > > Right now, there's

Hi all, My understanding is that we keep around KILL instructions in order to keep the results of the various register liveness analysis passes valid. Consider for example the following machine basic block: BB#0: derived from LLVM BB %entry Live Ins: %A0_64 %A1_64 %V0_64<def> = AND64 %A0_64<kill>, %A1_64<kill> %V0<def> = KILL %V0,

On 9 October 2015 at 23:44, Vasileios Kalintiris via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Both cmake & configure test for Python >= 2.7. Given the amount of python > code in the various scripts inside the LLVM projects, I wouldn't expect > Python 3.x to work for everything without changes. I use Arch, which defaults to Python 3, and I got no warnings from

On 9/8/14, 12:39 PM, Greg Fitzgerald wrote: > Hi Jon, > > Compiler-rt, libcxx, libcxxabi should all use the same > cross-compilation testing strategy. Compiler-rt already has a working > solution. If it is inadequate for libcxx or libcxxabi, can we start > by addressing those deficiencies? One issue to start with is that none of the libcxx/libcxxabi tests have RUN lines. All

Dan/Daniel/Eric, I'm testing a bare-metal ARM toolchain, and I've hacked up my local copy of lit to get it to run libcxx tests on qemu. I wanted to pick your collective brains to see if there was a better way of doing this. What I have implemented is here (don't take this as a formal review request, we can do that later once we figure out the best direction to go): lit part:

On 9/8/14, 3:31 PM, Greg Fitzgerald wrote: > Jon, > >> One issue to start with is that none of the libcxx/libcxxabi tests have RUN lines. > > Sorry, I didn't mean to imply that 'RUN:' lines should be added to > libcxx tests. It's fine that every one is implicitly: > > // RUN: %clang %s -o %t && %run %t > ... and then when an explicit

On 18 December 2014 at 21:32, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > I think this will help one facet of your problem: > http://reviews.llvm.org/D6584 I don't think so, because the tests don't time out, it's a buffering issue... --renato

Hi folks, I've updated the configuration for my libcxx buildbot (r220701) to pass some additional flags to compilation, including setting the CPU (so it won't need to use soft divide) and link flags + compiler-rt dependency to lit (so it won't fail with __aeabi_* symbols missing). Most problems should be all fixed once we reload the configuration in the build master. Right now,

So I started prototyping remote testing for libcxx over the weekend: https://github.com/jroelofs/libcxx/tree/remote_test The SSHExecutor isn't quite finished yet, but this should give an idea of what I've got in mind. Does this look generic enough to work for other projects under the llvm-umbrella (LNT, test-suite, compiler_rt, libcxxabi, etc)? Are there use cases that you see

Folks, I'm trying to set up a libc++ buildbot on ARM and I found an inconsistency which I'm not sure how to fix. I got a build error like this: libc++abi.so: undefined reference to `_Unwind_GetGR' Since I expected that the symbol would be provided by that library, I searched the CMake on libc++abi and found this: option(LIBCXXABI_USE_LLVM_UNWINDER "Build and use the LLVM

On Thu, Aug 03, 2017 at 08:22:24AM -0600, Jonathan Roelofs wrote: > IIUC, you don't want to cross compile llvm itself (which is what those > instructions are for), but instead you want to *use* llvm to cross compile > things. > > To build your sysroot, you'll need to cross-build: > > 1) A libc. Good choices for that for baremetal are: newlib or musl. > 2)

> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] > On Behalf Of Kuperstein, Michael M via llvm-dev > Subject: Re: [llvm-dev] Test Email - Apologies for the noise > I'm seeing the same issue here, also with Outlook. > Had to CC the list manually for this email) Same problem here - good to know it's not just me. For reference, I'm using Outlook version

On 09/27/2015 06:41 PM, Vasileios Kalintiris wrote: > Hi Richard, > > Clang doesn't have support for MIPS I. The trap-on-condition instructions were added in MIPS II and they should work fine. This is why it works with ".set mips32r2". > > Which version of the ISA did you specify when you used the integrated assembler? > > Thanks, > Vasileios > > Hi

On 14 August 2014 11:26, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > So you don't want to send it to the standard output. The things that want to parse it expect a file in the filesystem. So if you want the verbose build to be sticking it in a well-known file then I don't have strong objections, but it seems to be conflating two things. We run lit in -q mode in

You may also take a look at the ELLCC project (www.ellcc.org <http://www.ellcc.org/>). As far as I understand it they produce and package cross toolchains for a number of popular targets. - Matthias > On Aug 4, 2017, at 12:54 PM, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On 8/4/17 1:14 PM, Goran Mekić via llvm-dev wrote: >> On

On 5 September 2016 at 23:04, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > Let's first see how bad it is once bots are fixed to build the latest > revision. It's only been a few days and that includes a weekend. Of course. I'll wait until all our bots return from the first round to know the size of the damage. I just wanted to warn all other buildbot owners

Thanks Jon. Actually I tried “x86_64-linux”, but it makes the test “Unsupported” from my linux machine, and it was because my test is under clang, not llvm. It seems that clang doesn’t support “x86_64-linux” yet. Thanks again! Best, Taewook On 3/3/17, 10:57 AM, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote: On 3/3/17 11:46 AM, Taewook Oh via llvm-dev

Hi, Is there a rule or guideline about what Python versions must be supported for scripts in the LLVM tree? I am working on some patches to some scripts in LLVM to use features in Python 2.7, so that these scripts can run under Python 2.7 and Python 3.x Is that OK? For example, here is a patch to use print as a function, so that the scripts can work in Python 2.7 and Python 3.x -- Craig

Folks, Some of our CMake buildbots are failing to timeout, and I believe it's something to do with how the output comes from the LIT tests, even though we add -v to LIT_ARGS. When the "check-all" stage runs, the output stops at the "Running tests" message and only prints the rest of the output (including all tests that pass, fail, etc) at the end. I believe this has to