[Mono-dev] Bugzilla bug #81063 "[ARM] Hit assertion in inssel-float.brg(CEE_STIND_R4) - remoting, ARM, vfp softfloat"
lupus at ximian.com
Thu Aug 30 07:14:45 EDT 2007
On 08/30/07 Dean Jenkins wrote:
> I'm running some mono tests and some tests fail due to the assert for
> CEE_STIND_R4 being reached. There seems to be a float used in
> System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadValue in
> ReadArrayOfPrimitiveType() for case TypeCode.Single and I think that
> causes the assertion during JIT compilation.
> Can anyone explain why CEE_STIND_R4 has no soft float support but
> CEE_STIND_R8 is supported ?
By the time we reach the burg rules, all the CEE_STIND_R4 instructions
should have been removed when in soft-float mode. The reason is that
values on the evaluation stack are in double precision, because the
operations on them need to happen with that precision. This in turn
means that an freg as seen in the burg rules represents a double.
We can store a double with two simple integer stores, because it's just
a bit copy. The same cannot happen with a float, because that would
involve also a change in precision: this change is currently done with
an helper function (mono_fstore_r4) and at rules selection it's too late
to emit new function calls.
> Can anyone offer any solutions or provide some clues for me to fix it ?
> I'm wondering whether I can just adapt the CEE_STIND_R8 solution but I'm
> worried there is a technical reason why CEE_STIND_R4 has no soft float
See above for the reasons. I just went over mini.c again searching for
spots where we might not be handling the R4 case and found more than a
dozen cases (though some are in corner cases, eventually we need them
I have attached the diff with the cases marked with a FIXME: in most
cases the fix is trivial (like a cut&paste from the code that already
handles the R4 case correctly): I don't have a ready build/debug env
for soft-float right now, but if someone can extract a small test case
from the above bug report and post the output of running
mono -v -v -v -v -v test.exe
(just the output of the failing method), I can look at fixing that case
lupus at debian.org debian/rules
lupus at ximian.com Monkeys do it better
More information about the Mono-devel-list