search for: return_glob

...e.ll Unit-tests pass. Both A9 bots are running the same Ubuntu (13.03), with the same GCC (4.7.2), and are the same hardware (Panda ES RevB), so it really strikes me as odd that we have such a different behaviour between them. ARM920, compiled with GCC: All tests pass. Unit-test fail: MCJITTest.return_global If I take out the XFAIL on those tests, some bots will fail, others will pass. This is not the solution. It either pass on all, or none. All errors started with David's patch, so I'm assuming it was something enabled by that. It could be a dormant, unrelated bug to his patch, but it was...

Thanks for looking at this Tim. On a pandaboard, at least with the Release+Asserts config I tried, those tests do complain on stderr but llvm-lit thinks they've passed/expected fails, they don't actually count as fails like they do on the buildbot. Regarding solving PR16013 that looks like a relatively tractable job (on both 32-bit arm and aarch64) IF you're already familiar with the

...ne unittest below? Can you fix it? Or disable it on ARM? http://lab.llvm.org:8011/builders/llvm-armv5-linux/builds/298/steps/test-llvm/logs/LLVM-Unit%20%3A%3A%20ExecutionEngine__MCJIT____wd__buildbot__llvm-armv5-linux__llvm__unittests__ExecutionEngine__MCJIT__Debug%2BAsserts__MCJITTests__MCJITTest.return_global cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130518/3e5506b9/attachment.html>

On 18 May 2013 09:56, Tim Northover <t.p.northover at gmail.com> wrote: > According to Amara that assertion was a bit of paranoia so we'd know > if someone tried emitting .rel relocations and sending the result > through MCJIT. However, now we routinely re-relocate using explicit > addends so as he says it can probably just be removed. > Hi Tim, Sorry, I saw that thread

> Both A9 bots are running the same Ubuntu (13.03), with the same GCC (4.7.2), > and are the same hardware (Panda ES RevB), so it really strikes me as odd > that we have such a different behaviour between them. Hmm. I'll see what I can do on my tablet (not tried building LLVM there before so it could take a while), it seems like there are *some* failures everywhere. If we're