similar to: [LLVMdev] More ExecutionEngine XPASS on ARM

EE/JIT folks, When building release mode, 4 tests XPASS on ARM and I'm guessing is because they were relying on the assert being hit. Unexpected Passing Tests (4): LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll LLVM :: ExecutionEngine/2003-08-15-AllocaAssertion.ll LLVM :: ExecutionEngine/2003-08-23-RegisterAllocatePhysReg.ll LLVM ::

Hi, This is true for release_34 and trunk. Disabling assertions makes the following tests pass: Unexpected Passing Tests (5): LLVM :: ExecutionEngine/2003-05-06-LivenessClobber.ll LLVM :: ExecutionEngine/2003-08-15-AllocaAssertion.ll LLVM :: ExecutionEngine/2003-08-23-RegisterAllocatePhysReg.ll LLVM :: ExecutionEngine/MCJIT/cross-module-sm-pic-a.ll LLVM ::

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 ::

I think you mean to say: make check-all LIT_ARGS=--param=jit_impl=use-mcjit On 06/18/2012 08:24 PM, reed kotler wrote: > 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 ::

On Fri, Nov 4, 2011 at 3:11 PM, <spop at codeaurora.org> wrote: > Hi Daniel, > >> Sebastian, this looks like it is most likely some kind of fallout from >> your changes. > > Thanks for letting me know about these failing testcases. > > In the logs of the buildbot: >

Hi Daniel, > Sebastian, this looks like it is most likely some kind of fallout from > your changes. Thanks for letting me know about these failing testcases. In the logs of the buildbot: http://lab.llvm.org:8011/builders/llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi/builds/273/steps/run.build.step.configure_llvm_1/logs/stdio I see that the bot is configuring llvm with:

I actually tend to agree with spop, it's cleaner to compute things at runtime than at compile time. One particular reason is wanting to pick the best target CPU for the current arch (which may not be what was compiled for). The current JIT target selection logic is really gross, I do believe that it tried to do this, but it probably needs some spring cleaning. Sebastian, can you try and take

Building r80796 of the "release_26" branch on Ubuntu 9.04, I'm getting an XPASS on: ssen at ssen:~/llvm/build$ make TESTONE=FrontendC/2009-08-11- AsmBlocksComplexJumpTarget.c check-one make[1]: Entering directory `/home/ssen/llvm/build/test' Making a new site.exp file... XPASS: /home/ssen/llvm/test/FrontendC/2009-08-11- AsmBlocksComplexJumpTarget.c make[1]: Leaving directory

I finally had time to reproduce the failure in... http://llvm.org/bugs/show_bug.cgi?id=15817 under x86_64 Fedora 15 linux and it fails the same way as under x86_64-apple-darwin*... XPASS: Polly :: Isl/CodeGen/scevcodegen-1.ll (126 of 249) ******************** TEST 'Polly :: Isl/CodeGen/scevcodegen-1.ll' FAILED ******************** Script: -- opt -load

On Mon, 21 Jun 2004, Vladimir Merzliakov wrote: > Is it ok sending this results for FreeBSD5.1 at daily/weekly based to this > mail list? A better list for it would be the llvmbugs list for now. I beginning to think that we need a new test results mailing list. We have 3 instances of the nightly tester going now (x86/linux, sparc, ppc) and may have more in the future. The nightly tester

Hi, I've bootstrapped llvm/clang from svn-trunk on powerpc-darwin8 (g++-4.0.1), and have the following test results to share. Summary below, full log at: http://www.csl.cornell.edu/~fang/sw/llvm/r146586-powerpc-darwin8-results.txt The only edits required were those I posted to llvm-commits yesterday (re: "some missing clang libs"). And I also edited LitConfig.py to point to

Is it ok sending this results for FreeBSD5.1 at daily/weekly based to this mail list? Now results. Big improvement in llvm tests results from last test result sended. New regressions: Regression.Assembler.ConstantExprFold : FAIL , expected PASS Regression.CodeGen.Generic.2004-04-09-SameValueCoalescing: FAIL , expected PASS Regression.Transforms.PRE.basictest : FAIL

On Fri, Jul 8, 2011 at 9:30 AM, Karel Gardas <karel.gardas at centrum.cz> wrote: > On 07/ 8/11 05:26 PM, Eli Friedman wrote: >> >> Given that revision range, the only remotely likely culprit is 131463. >>  Which basically means that it "broke" because the default target >> features changed. > > And you are right here. 131463 == 131464 which is

On 07/ 8/11 05:26 PM, Eli Friedman wrote: > Given that revision range, the only remotely likely culprit is 131463. > Which basically means that it "broke" because the default target > features changed. And you are right here. 131463 == 131464 which is buggy. 131462 is OK. Thanks, Karel

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

Hi, I've got the same 4 unexpected passing tests on the AArch64 buildbot. I checked the buildbot logs and before these tests started to fail all MCJIT tests were unsupported. I think that maybe this commit - http://llvm.org/viewvc/llvm-project?revision=193459&view=revision <http://llvm.org/viewvc/llvm-project?revision=193459&view=revision> caused the issue but I'm still

Hi, Testing llvm trunk on openSUSE 13.1 ARMv7 I got 4 unexpected passes: Unexpected Passing Tests (4): LLVM :: ExecutionEngine/MCJIT/cross-module-sm-pic-a.ll LLVM :: ExecutionEngine/MCJIT/multi-module-sm-pic-a.ll LLVM :: ExecutionEngine/MCJIT/remote/cross-module-sm-pic-a.ll LLVM :: ExecutionEngine/MCJIT/remote/multi-module-sm-pic-a.ll And one FAIL: Failing Tests (1): LLVM ::

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?

So, it seems David beat me to it, and the assert has already been removed, but the failures are still inconsistent. A9-check-all, compiled with GCC: Tests XPASS: LLVM :: ExecutionEngine__MCJIT__test-common-symbols-remote.ll LLVM :: ExecutionEngine__MCJIT__test-global-init-nonzero-remote.ll LLVM :: ExecutionEngine__MCJIT__test-ptr-reloc-remote.ll Unit-tests pass. A9-self-host, compiled with

On Fri, May 31, 2013 at 10:59:52AM -0700, Tobias Grosser wrote: > On 05/31/2013 10:11 AM, Sebastian Pop wrote: >> Sebastian Pop wrote: >>> Sebastian Pop wrote: >>>> Jack Howarth wrote: >>>>> The attached patch eliminates http://llvm.org/bugs/show_bug.cgi?id=15817 by removing the remaining >>>>> "; XFAIL:*" added in