Hi Ramana,

   We know the limit of the QEMU and already noticed failure due to
the simulator.  Like I said, this is used as the baseline.  We are
going to look at the failures carefully to categorize them.  We
noticed that some tests fail randomly on QEMU, these are marked as
flaky and the validator script ignores those.



On Mon, Mar 12, 2012 at 3:57 PM, Ramana Radhakrishnan
<ramana.radhakrish...@linaro.org> wrote:
> On 12 March 2012 18:58, Doug Kwan <dougk...@google.com> wrote:
>> Hi Diego
>>        This patch adds arm-grtev2-linux-gnueabi.xfail for our 4.6 branch
>>        so that we can track regressions.  This just established the test
>>        baseline.  The failures need to be investigated.
> Just out of curiosity, were these when you ran them cross on qemu or
> when you ran these native. It's probably worth noting that as well.
> There are times when you'll see differences in test results especially
> on recent trunk ( atomic tests depend on the version of gdb installed
> , cross testing on qemu pretty much means threaded tests are well
> let's say flaky) .
> This is probably something that ought to be recorded along with the
> environment in which the tests were run to ease comparison.
> This failure here suggests that you are runing on qemu.
> +FAIL: gfortran.dg/vect/fast-math-pr38968.f90 execution test
> I've noticed that this is something that times out depending on the
> orientation of the sun , moon and earth and the performance of qemu on
> your machine but on a native device runs just fine.
> regards,
> Ramana

Reply via email to