gitlab scraper: download in toml and text format

1 files changed, 33 insertions, 0 deletions

diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2340 b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2340
new file mode 100644
index 000000000..f668e6619
--- /dev/null
+++ b/gitlab/issues_text/target_sparc/host_missing/accel_missing/2340
@@ -0,0 +1,33 @@
+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