search for: argumentbug

...and grep for FAILED in logfile, does what's listed there give any more details? (Quite possible in a Release-Asserts build > it might not.) All these tests fail with 'illegal instruction' signal. For example: ******************** TEST 'LLVM :: ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll' FAILED ******************** Script: -- /home/grib/clang/llvm-build-armhf/Release+Asserts/bin/lli -mtriple=armv7l-unknown-linux-gnueabihf -use-mcjit /home/grib/clang/llvm/test/ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll > /dev/null -- Exit Code: 132 Command Output (stderr): -- Stack d...

...al box). [...] > LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll > LLVM :: Transforms/LoopStrengthReduce/2012-07-18-LimitReassociate.ll It is interesting that I don't see this on my ARM box. Instead I see these: Failing Tests (5): LLVM :: ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll LLVM :: ExecutionEngine/MCJIT/pr13727.ll LLVM :: ExecutionEngine/MCJIT/test-common-symbols.ll LLVM :: ExecutionEngine/MCJIT/test-fp-no-external-funcs.ll LLVM :: ExecutionEngine/MCJIT/test-fp.ll I configure with: --build=armv7l-unknown-linux-gnueabihf --host=armv7l-unknown-linux-...

...does what's listed there give any more > details? (Quite possible in a Release-Asserts build > > it might not.) > > All these tests fail with 'illegal instruction' signal. For example: > > ******************** TEST 'LLVM :: > ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll' FAILED > ******************** > Script: > -- > /home/grib/clang/llvm-build-armhf/Release+Asserts/bin/lli > -mtriple=armv7l-unknown-linux-gnueabihf -use-mcjit > /home/grib/clang/llvm/test/ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll > > /dev/null > -- > Exit...

...Global Mapping with function descriptor instead of the function address. The JIT function descriptor is loaded correctly in 'JIT::runFunction', instead of assuming the JIT function code is an ODP. Now I'm trying to make the relocation work properly. Using the testcase '2003-01-04-ArgumentBug' the assembly generated for main functions is the following: .L.main: # BB#0: mflr 0 std 0, 16(1) stdu 1, -112(1) lis 3, .LCPI1_0 at ha li 4, 1 lfs 1, .LCPI1_0 at l(3) li 3, 0 bl foo nop addi 1, 1, 112...

...or instead of the function address. The JIT function descriptor is > > loaded correctly in 'JIT::runFunction', instead of assuming the JIT function code is > > an ODP. > > > > Now I'm trying to make the relocation work properly. Using the testcase '2003-01-04-ArgumentBug' > > the assembly generated for main functions is the following: > > > > .L.main: > > # BB#0: > > mflr 0 > > std 0, 16(1) > > stdu 1, -112(1) > > lis 3, .LCPI1_0 at ha > > li 4, 1 > >...

...al box). [...] > LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll > LLVM :: Transforms/LoopStrengthReduce/2012-07-18-LimitReassociate.ll It is interesting that I don't see this on my ARM box. Instead I see these: Failing Tests (5): LLVM :: ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll LLVM :: ExecutionEngine/MCJIT/pr13727.ll LLVM :: ExecutionEngine/MCJIT/test-common-symbols.ll LLVM :: ExecutionEngine/MCJIT/test-fp-no-external-funcs.ll LLVM :: ExecutionEngine/MCJIT/test-fp.ll I configure with: --build=armv7l-unknown-linux-gnueabihf --host=armv7l-unknown-linux-...

...encing it. > > Thanks, > -Will Thanks for the reply Duncan, I shifted my focus fo MCJIT. So far I could check there are basically two issues with MCJIT relating to PPC64 support: 1. Looks like LLVM does not generate PPC64 PIC code with TOC references. Using the testcase '2003-01-04-ArgumentBug.ll' I tried to invoke the llc with '-march=ppc64 -mcpu=ppc64 -mattr=64bit' and still uses the 32-bits relocations (@ha/@l(3)) where TOC would be expected (@toc). I did some adjustments to JIT code and function calling is correct (the function ODP is created and called), but BSS access i...

...2/Debug+Asserts/bin/llc < /nfs_home/chenwj/test/llvm/test/CodeGen/Thumb/select.ll -mtriple=thumb-apple-darwin | grep __ltdf2 -- Exit Code: 1 Command Output (stderr): -- Expected 3 lines, got 1. -- ******************** Testing: 0 .. 10.. 20.. 30.. 40.. 50 FAIL: LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll (3173 of 6030) ******************** TEST 'LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll' FAILED ******************** Script: -- /nfs_home/chenwj/test/native-build/arm2/Debug+Asserts/bin/lli /nfs_home/chenwj/test/llvm/test/ExecutionEngine/2003-01-04-ArgumentBug.ll > /dev/null -- Ex...

...fails are due to the fact that the testcases are not working when the target is specified to be different than host: in the following list of failing testcases I see the JIT cases failing: Failing Tests (26): LLVM :: ExecutionEngine/2002-12-16-ArgTest.ll LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll LLVM :: ExecutionEngine/2003-01-04-LoopTest.ll LLVM :: ExecutionEngine/2003-01-15-AlignmentTest.ll LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll LLVM :: ExecutionEngine/2003-05-07-ArgumentTest.ll LLVM :: ExecutionEngine/2003-06-04-bzip2-bug.ll LLVM :: ExecutionEng...

...t; function descriptor instead of the function address. The JIT function descriptor is > loaded correctly in 'JIT::runFunction', instead of assuming the JIT function code is > an ODP. > > Now I'm trying to make the relocation work properly. Using the testcase '2003-01-04-ArgumentBug' > the assembly generated for main functions is the following: > > .L.main: > # BB#0: > mflr 0 > std 0, 16(1) > stdu 1, -112(1) > lis 3, .LCPI1_0 at ha > li 4, 1 > lfs 1, .LCPI1_0 at l(3) > li 3, 0 &...

..., >> -Will > Thanks for the reply Duncan, I shifted my focus fo MCJIT. So far I could check there are basically > two issues with MCJIT relating to PPC64 support: > > 1. Looks like LLVM does not generate PPC64 PIC code with TOC references. Using the testcase > '2003-01-04-ArgumentBug.ll' I tried to invoke the llc with '-march=ppc64 -mcpu=ppc64 -mattr=64bit' > and still uses the 32-bits relocations (@ha/@l(3)) where TOC would be expected (@toc). I did some > adjustments to JIT code and function calling is correct (the function ODP is created and called), > b...

On 06/18/2012 07:21 PM, 陳韋任 (Wei-Ren Chen) wrote: > make check-all LIT_ARGS=--param=jit_impl=mcjit Thanks. When I run this on x86 ubuntu, there are 47 failures. Failing Tests (47): LLVM :: ExecutionEngine/MCJIT/2002-12-16-ArgTest.ll LLVM :: ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll LLVM :: ExecutionEngine/MCJIT/2003-01-04-LoopTest.ll LLVM :: ExecutionEngine/MCJIT/2003-01-04-PhiTest.ll LLVM :: ExecutionEngine/MCJIT/2003-01-09-SARTest.ll LLVM :: ExecutionEngine/MCJIT/2003-01-10-FUCOM.ll LLVM :: ExecutionEngine/MCJIT/2003-01-15-AlignmentTest.ll L...

...that the testcases are not > working when the target is specified to be different than host: in the > following list of failing testcases I see the JIT cases failing: > > Failing Tests (26): >    LLVM :: ExecutionEngine/2002-12-16-ArgTest.ll >    LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll >    LLVM :: ExecutionEngine/2003-01-04-LoopTest.ll >    LLVM :: ExecutionEngine/2003-01-15-AlignmentTest.ll >    LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll >    LLVM :: ExecutionEngine/2003-05-07-ArgumentTest.ll >    LLVM :: ExecutionEngine/2003-06-04-bzip2-bug.ll >...

The following failures are consistent on buildbot (and my local box). The Clang one I think it's assuming an Intel box, the other two look like the FileCheck are not good enough. http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/4305 Clang :: CodeGen/compound-assign-overflow.c LLVM :: Transforms/LoopStrengthReduce/post-inc-icmpzero.ll LLVM ::

On Mon, Jun 18, 2012 at 04:56:53PM -0700, reed kotler wrote: > I don't see any tests in either test or test-suite for -use-mcjit. For ARM, we need to manually switch to use mcjit, say $ make check-all LIT_ARGS=--param=jit_impl=mcjit Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799

...(Wei-Ren Chen) wrote: >> make check-all LIT_ARGS=--param=jit_impl=mcjit > Thanks. > > When I run this on x86 ubuntu, there are 47 failures. > > Failing Tests (47): > LLVM :: ExecutionEngine/MCJIT/2002-12-16-ArgTest.ll > LLVM :: ExecutionEngine/MCJIT/2003-01-04-ArgumentBug.ll > LLVM :: ExecutionEngine/MCJIT/2003-01-04-LoopTest.ll > LLVM :: ExecutionEngine/MCJIT/2003-01-04-PhiTest.ll > LLVM :: ExecutionEngine/MCJIT/2003-01-09-SARTest.ll > LLVM :: ExecutionEngine/MCJIT/2003-01-10-FUCOM.ll > LLVM :: ExecutionEngine/MCJIT/2003...

Le mardi 27 mars 2012 à 14:36 -0700, Bill Wendling a écrit : > IMPORTANT! IMPORTANT! IMPORTANT! > [...] > By the way, we are looking for ARM testers. There was a lot of interest in the 3.0 release for an ARM release. We will try to do one this release on a trial basis. We are looking for ARMv7 cortex-a8 and cortex-a9 on Linux. If you are interested, I can upload the current trunk

...ot >> working when the target is specified to be different than host: in the >> following list of failing testcases I see the JIT cases failing: >> >> Failing Tests (26): >>    LLVM :: ExecutionEngine/2002-12-16-ArgTest.ll >>    LLVM :: ExecutionEngine/2003-01-04-ArgumentBug.ll >>    LLVM :: ExecutionEngine/2003-01-04-LoopTest.ll >>    LLVM :: ExecutionEngine/2003-01-15-AlignmentTest.ll >>    LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll >>    LLVM :: ExecutionEngine/2003-05-07-ArgumentTest.ll >>    LLVM :: ExecutionEngine/2003-06-...

...log we have so far. > > Hi all, > The changes so far are an attempt to get existing test cases to run. So > I'd argue against the changes being considered new features. :-) > Yea, new features is probably the wrong word. Let's say "new code". =] > 2003-01-04-ArgumentBug.ll is the one chosen at random that Adhemerval > has been focused on. That wasn't called out explicitly, and we do > expect some number of test cases to begin functioning better once this > initial batch of patches gets worked into the tree. > This is good, but where is this test?...

I don't see any tests in either test or test-suite for -use-mcjit. Are we not testing this yet? There are lots of other llc options. What is our plan for testing these?