similar to: No longer able to run lit tests within a sub-tool

This works for me. Can you run "which clang-func-mapping" and also add a line to clang/test/lit.cfg.py to print the value of config.environment['PATH']? On Fri, Sep 22, 2017 at 11:27 AM Zachary Turner <zturner at google.com> wrote: > Looking, thanks for the report. > > On Fri, Sep 22, 2017 at 11:22 AM Vedant Kumar <vsk at apple.com> wrote: > >> As

Looking, thanks for the report. On Fri, Sep 22, 2017 at 11:22 AM Vedant Kumar <vsk at apple.com> wrote: > As of r313998, this workflow no longer works: > > cd <build-dir> > ./bin/llvm-lit <src>/llvm/tools/clang/test/CoverageMapping > > I get: > > llvm-lit: /Users/vk/src/llvm.org-coverage-braces/llvm/tools/clang/test/ > lit.cfg.py:97: note: using

> On Sep 22, 2017, at 11:36 AM, Vedant Kumar <vsk at apple.com> wrote: > > Ah, the problem goes away once I build clang-func-mapping. > > I stripped some stuff out, but here's pretty much what clang/test/lit.cfg.py says my PATH is: > > ** PATH **: /Volumes/Builds/llvm.org-coverage-braces-RA/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin > > I wonder how

Ah, the problem goes away once I build clang-func-mapping. I stripped some stuff out, but here's pretty much what clang/test/lit.cfg.py says my PATH is: ** PATH **: /Volumes/Builds/llvm.org-coverage-braces-RA/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin I wonder how this ever worked before, when I didn't have clang-func-mapping built. Anyway, thanks for your help! vedant >

Yea at first I was worried that maybe I changed the semantics of how it looked in PATH, and you had clang-func-mapping in your PATH somewhere before but now lit was building a different PATH. But I looked at that change and it wasn't even creating that substitution before. So it looks like that CL is indeed the problem. On Fri, Sep 22, 2017 at 11:38 AM Vedant Kumar <vsk at apple.com>

Hello, LLVM community. I've built a cross-toolchain on Windows and I'm now trying to run unit tests for the LLVM libraries. I used Ninja as a build system and MSVC as host compiler without an issue, but when I try to run 'ninja check-llvm-unit', I get the following error: llvm-lit.py: C:/Users/sergej/Developer/llvm-project/llvm\utils\lit\lit\TestingConfig.py:102: fatal: unable

Got it. Attached are both the testcase & the fix. On Tue, Jul 17, 2018, at 12:06, Carlo Kok via llvm-dev wrote: > On Wed, Jul 11, 2018, at 16:45, Davide Italiano wrote: > > On Tue, Jul 10, 2018 at 10:12 PM Carlo Kok via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > > > > > > That sounds quite reasaonable; how does one usually go about doing that?

Sorry, I was thinking to review the test but didn't. Is this test complete? It does invoke lld, but it didn't verify its output. On Mon, Jul 30, 2018 at 2:03 PM Andrew Kelley <superjoe30 at gmail.com> wrote: > Ping Rui. Is there anything else that needs to be done on this patch? > > On Tue, Jul 17, 2018 at 6:58 AM, Carlo Kok via llvm-dev < > llvm-dev at

Hi, while experimenting with llvmlinux on Debian/testing AMD64 I wanted to run some x86-64 ASM tests. I fell over [1] and wanted to run it. So, I cloned clang from Git... $ git clone https://github.com/llvm-mirror/clang.git I looked through some docs where I have seen I need "llvm-lit" or "lit.py". The Debian package llvm-7-tools from <apt.llvm.org> does ship

It looks like this broke green dragon: http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40383/console llvm-lit: /Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/projects/libcxx/utils/libcxx/test/config.py:173: note: Adding environment variables: {'DYLD_LIBRARY_PATH': '/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/./lib',

> On Nov 10, 2017, at 2:50 PM, Zachary Turner <zturner at google.com> wrote: > > I checked in a fix for that already, sorry for the trouble. I’m waiting for it to cycle awesome. Thanks! -- adrian > On Fri, Nov 10, 2017 at 2:49 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > It looks like this broke green dragon: > >

On Tue, Jul 10, 2018 at 10:12 PM Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > That sounds quite reasaonable; how does one usually go about doing that? a repro zip that hits both asserts? > You can take inspiration from anything in lld/test, but basically either an assembly source (or multiple) passed through llvm-mc and then lld, or a YAML file passed to yaml2obj

The simplest way to run a clang test case that I know of is to clone both llvm and clang repos, run all the tests, then run an individual test. IIRC like so: git clone llvm ...... cd llvm/tools git clone clang ..... cd ../../ mkdir build cd build cmake ../llvm ninja check-clang ./bin/llvm-lit -v ./tools/clang/test/Sema/asm.c On Sun, May 6, 2018 at 7:10 AM, Sedat Dilek via llvm-dev <

It looks like the bots are still red? — Adrian > On Nov 10, 2017, at 3:14 PM, Zachary Turner <zturner at google.com> wrote: > > Wasn't quite fixed, but it got a lot further this time. This time there was still an issue in the test_debuginfo.pl <http://test_debuginfo.pl/> script regarding a hardcoded path to the llgdb.py script. I think I never encountered this locally

On the other hand this file hasn't changed recently, but I have no way to test this as it uses the LLDB code path, which only runs on OSX. On Mon, Nov 13, 2017 at 3:19 PM Zachary Turner <zturner at google.com> wrote: > I might be missing something, but this doesn't look like me? > > >

Since this is causing all of our internal CI to back up, could you please revert your two changes, so we can make sure that they were actually responsible, and can work on a fix for this? Let me know how we can help investigate this. -- adrian > On Nov 13, 2017, at 3:25 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The first build where a test fails with

Yes I can reproduce this locally. It looks like we are not passing an -isysroot (pointing to the SDK) to clang but it isn’t clear what lit magic would expand this. -- adrian > On Nov 13, 2017, at 3:30 PM, Zachary Turner <zturner at google.com> wrote: > > Yea I'm preparing a revert right now. Does it happen for you when you run debuginfo-tests locally? > > On Mon, Nov

Yea I also just found it. Try adding this code in the bottom of debuginfo-tests/lit.cfg.py lit.util.usePlatformSdkOnDarwin(config, lit_config) On Mon, Nov 13, 2017 at 4:38 PM Adrian Prantl <aprantl at apple.com> wrote: > Ha! Found it. *Somebody* is setting an SDKROOT variable in the > environment. Can you find the code that would do this? > > — adrian > > > On Nov

On Sat, Feb 14, 2009 at 00:17, <ashrafi@ucdavis.edu> wrote: Hi, I was trying to read ~400 chips in an affybatch and I got the same message. Could you find a remedy for that. My server has 128 GB of RAM. However, R halted ever before it uses the memory. I have been able to load upto 250 CEL files but this time I wanted to test what would happen if I want to normalize 400 chips. Thanks

I sorta enjoy debugging stuff like this, so if you don't mind, I'll dig into it once I get a chance -- traveling so, my access is a bit sketchy right now. I'll see if I can grab the logs and let you know if I find anything interesting. On Tue, Nov 21, 2017 at 7:04 PM, Zachary Turner <zturner at google.com> wrote: > That change was added specifically to workaround a failure