similar to: Cannot run LLVM unit tests doe to python error in lit

Displaying 20 results from an estimated 800 matches similar to: "Cannot run LLVM unit tests doe to python error in lit"

2019 Sep 01
3
MCJIT on cross-toolchain?
I apologize in advance if this is a somewhat silly question (I’m making my first steps in the infrastructure), but still. Is it true that if an LLVM toolchain is compiled as a cross-toolchain, MCJIT is not expected to work? I’m still working on a toolchain that cross-compiles from Windows to ARM Linux, and I’ve managed to get clang and lld tests to pass, but some (not all) MCJIT tests are
2017 Sep 22
2
No longer able to run lit tests within a sub-tool
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 clang: '/Volumes/Builds/llvm.org-coverage-braces-RA/bin/clang' llvm-lit:
2018 Jul 17
2
lld/mach-o x86_64 asserts
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?
2017 Sep 22
2
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
2017 Sep 22
0
No longer able to run lit tests within a sub-tool
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
2018 Jul 30
3
lld/mach-o x86_64 asserts
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
2017 Sep 22
2
No longer able to run lit tests within a sub-tool
> 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
2017 Sep 22
0
No longer able to run lit tests within a sub-tool
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 >
2019 Nov 20
2
libunwind is not configured with -funwind-tables when building it for ARM Linux?
> On 18 Nov 2019, at 22:11, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 17:06, Sergej Jaskiewicz <jaskiewiczs at icloud.com <mailto:jaskiewiczs at icloud.com>> wrote: >> >> >> >> On 18 Nov 2019, at 19:55, Peter Smith <peter.smith at linaro.org> wrote: >> >> On Mon, 18 Nov 2019 at 15:23, Sergej
2017 Sep 22
0
No longer able to run lit tests within a sub-tool
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>
2018 May 06
3
[clang] Running a single testcase
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
2019 Nov 18
2
libunwind is not configured with -funwind-tables when building it for ARM Linux?
> On 18 Nov 2019, at 19:55, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 15:23, Sergej Jaskiewicz <jaskiewiczs at icloud.com <mailto:jaskiewiczs at icloud.com>> wrote: >> >> Hi Peter, >> >> Thanks for your response. >> >> On 18 Nov 2019, at 17:44, Peter Smith <peter.smith at linaro.org> wrote:
2017 Nov 10
2
PSA: debuginfo-tests workflow changing slightly
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',
2017 Nov 10
2
PSA: debuginfo-tests workflow changing slightly
> 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: > >
2019 Nov 18
2
libunwind is not configured with -funwind-tables when building it for ARM Linux?
Hi Peter, Thanks for your response. > On 18 Nov 2019, at 17:44, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 12:32, Sergej Jaskiewicz via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> There’s this bug: https://bugs.llvm.org/show_bug.cgi?id=38468
2018 Jul 11
2
lld/mach-o x86_64 asserts
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
2018 May 07
0
[clang] Running a single testcase
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 <
2017 Nov 13
2
PSA: debuginfo-tests workflow changing slightly
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
2017 Nov 22
2
PSA: debuginfo-tests workflow changing slightly
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
2017 Nov 25
2
PSA: debuginfo-tests workflow changing slightly
Hi Zachary: I was able to reproduce the greendragon results locally (OSX), and fix the problem by excluding 'debuginfo-tests' from check-clang -- this prevents them from being added twice, once for check-clang and again for check-debuginfo. Below are the minimized patches I used to reproduce and fix the problem -- based on your originals. I've verified these patches work when