diff options
Diffstat (limited to 'gitlab/issues_text/target_sparc/host_missing/accel_missing/2340')
| -rw-r--r-- | gitlab/issues_text/target_sparc/host_missing/accel_missing/2340 | 33 |
1 files changed, 0 insertions, 33 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 deleted file mode 100644 index f668e6619..000000000 --- a/gitlab/issues_text/target_sparc/host_missing/accel_missing/2340 +++ /dev/null @@ -1,33 +0,0 @@ -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 |