architecture: 0.972
graphic: 0.952
performance: 0.888
ppc: 0.843
device: 0.774
kernel: 0.762
vnc: 0.732
assembly: 0.717
risc-v: 0.688
debug: 0.664
boot: 0.654
semantic: 0.628
peripherals: 0.592
arm: 0.587
socket: 0.567
permissions: 0.530
PID: 0.491
register: 0.468
TCG: 0.463
network: 0.461
i386: 0.431
VMM: 0.428
files: 0.413
user-level: 0.341
KVM: 0.314
virtual: 0.244
x86: 0.236
mistranslation: 0.128
hypervisor: 0.064

SPARC fp operation INVALID  trap hangs on offending instruction.
Description of problem:
An IEEE Invalid Operation exception is typically not enabled in programs - but if it is and an Invalid Operation occurs, a hardware TRAP should be generated which eventually becomes a SIGFPE.   However, instead, the program seems to hang on the offending instruction, never moving forward.

This small C example (you'll need a C compiler) demonstrates the problem, by enabling the INValid floating-pt exception, then executing the FDTOI instruction which causes an INValid trap because the floating-pt source operand is too large for the 32-bit integer result .  The SPARC V9 manual specifies that exception should happen, so it's correct to generate the trap.   However, the program simply hangs on the FDTOI instruction instead of receiving the signal.

It could be something in trap emulation that is the underlying culprit here - other possible IEEE traps (such as division-by-zero) might similarly fail?

`#include <ieeefp.h>`

`main()`

`{` 

  `double val;`

  `int i;`

  `fpsetmask(FP_X_INV);`

  `val = 1000000000000003.0; /* Number that is too large for int */`

  `printf("val is %f\n", val);`

  `i = val;`

  `printf("i is %d\n", i);`

`}`
Steps to reproduce:
1. Enable IEEE iNValid operation traps in the TEM in the FSR.
2. Generate an instruction that causes an iNValid trap
3. Instruction hangs, no SIGFPE is generated