1 files changed, 46 insertions, 0 deletions
diff --git a/results/classifier/105/graphic/2340 b/results/classifier/105/graphic/2340
new file mode 100644
index 00000000..02e90a52
--- /dev/null
+++ b/results/classifier/105/graphic/2340
@@ -0,0 +1,46 @@
+graphic: 0.952
+instruction: 0.927
+device: 0.774
+vnc: 0.732
+assembly: 0.717
+boot: 0.654
+semantic: 0.628
+other: 0.581
+socket: 0.567
+network: 0.461
+KVM: 0.314
+mistranslation: 0.128
+
+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