I think I may have reported this before, but ran into it again today.
Hatari's WinUAE appears to be ignoring the 68881's precision and rounding control bits.
These bits determine nearest or chop rounding, which are quite important when trying to convert to/from fixedpoint values.
This causes small negative numbers (e.g. -0.0001) to round to zero when the integer part is extracted, and when subtracted and scaled to extract the fraction in fixed point form, it produces a negative value. This generates an invalid fixedpoint value (integer & fraction differently signed) in my code.
It can be worked around by using a carefully chosen bias during conversion, and configuring round-to-nearest (which is what it seems to be doing regardless of FPCR) but this wasteful, and only works for an expected range anyway.