Different behaviour of RTEMS in QEMU/i386 and SPARC

[Constantine "chicky" Giotopoulos]

So could it be Qemu?
I would surely expect that running "paranoia" floating-point operations on
Qemu/i386 would produce more defects, flaws, etc in the final  paranoia's
"report", than when running the same operations in an i386 out of Qemu.
But could the "hanging" (as I mentioned before, it doesn't actually STOPS
executing, it just hangs there as if it fell on an infinite loop or
something else) in that specific part of the code be realistically a result
of Qemu issues?

On Mon, Oct 31, 2011 at 12:26 PM, Joel Sherrill
<joel.sherrill at oarcorp.com>wrote:

> QEMU for i386 has FP issues which are not present on real hardware. It
> does not maintain enough precision to make some of the Ada ACATS tests
> pass. I investigated those failures and it was the simulator. Any test
> which depends on very accurate IEEE754 is not going to be happy on qemu
> i386.
>
> --joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20111031/85afcfad/attachment-0001.html>