Documentation says:
--
6.6.2.2 TRAP ENABLED RESULTS (FPCR SNAN BIT SET).
If the destination is not a floating-point data register (FMOVE OUT
instruction), the destination (memory or integer data register) is
written with the same data as though the trap were disabled (FPCR SNAN
bit clear), and then control is passed to the user SNAN handler as a
post-instruction exception. If desired, the user SNAN handler can
overwrite the result.
For floating-point data register destinations, the source (if
register-to-register instruction) and destination floating-point data
registers are not modified. Control is passed to the user SNAN handler
as a pre-instruction exception when the next floating-point instruction
is encountered. In this case, the SNAN user handler should supply the
result.
--
So according to documentation (Test code has FP0 destination), following
FPU instruction should trigger the SNAN exception. But test code expects
immediate post-instruction exception and gets confused if it gets
delayed until next FPU instruction.
I did some real 68060 tests. As usual, documentation does not want to
tell the whole truth.
It mentions many times something like "Since FMOVE to/from the FPCR,
FPSR, or FPIAR and FMOVEM instructions cannot generate floating-point
exceptions, you can do blahblahblah" but this only means those
instructions can't generate exceptions internally and won't modift FPIAR
(so that FPIAR still points to instruction that caused the exception)
but they do still cause exception if there is pending FPU exception
generated by previous FPU instruction. Even FMOVEM.X does this.
This explains why SNAN, OPERR and DZ tests work.
Patch coming later..