[Mono-dev] Bugzilla bug #81063 "[ARM] Hit assertion in inssel-float.brg(CEE_STIND_R4) - remoting, ARM, vfp softfloat"

[Dean Jenkins]

Hi lupus,

BTW. Your E-mail did not contain an attachment. Please can you try
again ? Perhaps add your attachment to the bugzilla bug #81063 ?

Also, I can't access the attachment in bugzilla from the original
reporter of the bug. My Firefox browser wants to save the cgi script and
not the attachment :(

I temporarily removed the asserts in CEE_STIND_R4 and CEE_LDIND_R4 and
put some debug in mono_fstore_r4() and mono_fload_r4(). The helper
functions seem to be containing floats OK when I run my C# test script.
Output from my script seems to be OK.

At the moment I do have access to a XScale platform that uses soft float
in JIT. If you have some test code or code snippets I could integrate it
and do a mono build and test it.

Thanks,

Regards,
Dean.
MontaVista Software Ltd.

On Thu, 2007-08-30 at 13:14 +0200, Paolo Molaro wrote:
> 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
> > support.
> 
> 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
> all fixed).
> 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
> at least.
> 
> lupus
>