1 files changed, 26 insertions, 0 deletions
diff --git a/results/scraper/launchpad-without-comments/1883984 b/results/scraper/launchpad-without-comments/1883984
new file mode 100644
index 000000000..1ead13c9f
--- /dev/null
+++ b/results/scraper/launchpad-without-comments/1883984
@@ -0,0 +1,26 @@
+QEMU S/390x sqxbr (128-bit IEEE 754 square root) crashes qemu-system-s390x
+
+In porting software to guest Ubuntu 18.04 and 20.04 VMs for S/390x, I discovered
+that some of my own numerical programs, and also a GNU configure script for at
+least one package with CC=clang, would cause an instant crash of the VM, sometimes
+also destroying recently opened files, and producing long strings of NUL characters
+in /var/log/syslog in the S/390 guest O/S.
+
+Further detective work narrowed the cause of the crash down to a single IBM S/390
+instruction: sqxbr (128-bit IEEE 754 square root).  Here is a one-line program
+that when compiled and run on a VM hosted on QEMUcc emulator version 4.2.0 
+(Debian 1:4.2-3ubuntu6.1) [hosted on Ubuntu 20.04 on a Dell Precision 7920 
+workstation with an Intel Xeon Platinum 8253 CPU],  and also on QEMU emulator 
+version 5.0.0, reproducibly produces a VM crash under qemu-system-s390x.
+
+% cat bug-sqrtl-one-line.c
+int main(void) { volatile long double x, r; x = 4.0L; __asm__ __volatile__("sqxbr %0, %1" : "=f" (r) : "f" (x)); return (0);}
+
+% cc bug-sqrtl-one-line.c && ./a.out
+Segmentation fault (core dumped)
+
+The problem code may be the function float128_sqrt() defined in qemu-5.0.0/fpu/softfloat.c
+starting at line 7619.  I have NOT attempted to run the qemu-system-s390x executable
+under a debugger.  However, I observe that S/390 is the only CPU family that I know of,
+except possibly for a Fujitsu SPARC-64, that has a 128-bit square root in hardware.
+Thus, this instruction bug may not have been seen before.
\ No newline at end of file