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