SPARC fp operation INVALID trap hangs on offending instruction.

Host environment

• Operating system: FreeBSD

• OS/kernel version: 13.3

• Architecture: amd64

• QEMU flavor: SPARC

• QEMU version: 9.0.0

• QEMU command line:

  ./qemu-9.0.0/build/qemu-system-sparc -M SS-5 -m 256 -drive file=sparc.qcow2,bus=0,unit=0,media=disk -drive file=solaris_7_1199_sparc.iso,bus=0,unit=2,media=cdrom,readonly=on -nographic -net nic,macaddr=52:54:0:12:34:58 -net tap,ifname=tap5,script=no,downscript=no

Emulated/Virtualized environment

• Operating system: SunOS (Solaris)
• OS/kernel version: 5.7
• Architecture: SPARC32 (SS-5)

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

Additional information