|
From: | Robert Reif |
Subject: | Re: [Qemu-devel] [sparc] Floating point exception issue |
Date: | Sat, 22 Jan 2011 11:45:56 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101206 SeaMonkey/2.0.11 |
Blue Swirl wrote:
There is still a floating point exception problem that may or may not be related.On Sat, Jan 22, 2011 at 3:30 PM, Mateusz Loskot<address@hidden> wrote:On 18/01/11 21:51, Blue Swirl wrote:On Tue, Jan 18, 2011 at 6:00 PM, Mateusz Loskot<address@hidden> wrote:On 18/01/11 17:36, Blue Swirl wrote:On Tue, Jan 18, 2011 at 3:27 PM, Mateusz Loskot<address@hidden> wrote:Hi, Recently, I have reported mysterious issues on NetBSD 5.1 emulated on SPARC. The whole first thread is here: http://lists.gnu.org/archive/html/qemu-devel/2011-01/msg01509.html I decided to investigate the problem deeper and with great help from NetBSD folks, I managed to find reproducible test case. Initially, it was AWK command: # echo NaN | awk '{print "test"}' awk: floating point exception 8 source line number 1 and next it boiled down to simple C program (see below). Details of the investigation are archived in the NetBSD Problem Report #44389 here: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=44389 Here is final version of the test program which reproduces the problem: #include<stdio.h> #include<stdlib.h> #include<math.h> #include<errno.h> int is_number(const char *s) { double r; char *ep; errno = 0; r = strtod(s,&ep); if (r == HUGE_VAL) printf("X:%g\n", r); if (ep == s || r == HUGE_VAL || errno == ERANGE) return 0; while (*ep == ' ' || *ep == '\t' || *ep == '\n') ep++; if (*ep == '\0') return 1; else return 0; } int main(int argc, char **argv) { double v; if (is_number("NaN")) { printf("is a number\n"); v = atof("NaN"); } else { printf("not a number\n"); v = 0.0; } printf("%.4f\n", v); return 0; } On NetBSD/SPARC, the program receives SIGFPE: $ gcc ./nan_test_2.c $ ./a.out [1] Floating point exception (core dumped) ./a.out Specifically, it's caused by r == HUGE_VAL condition in if (ep == s || r == HUGE_VAL || errno == ERANGE) where r is NaN. All the signs indicate there is a bug in QEMU.I'll install 5.1, but on 4.0 which I had installed, the program works fine: $ ./sigfpe is a number nanI just tested on NetBSD 5.0/SPARC under QEMU 0.13 (same version I use with NetBSD 5.1/SPARC) and it works well indeed: address@hidden:~/tmp# ./a.out is a number nan address@hidden:~/tmp# Hmm, this is becoming interesting. I run QEMU 0.13 on Windows Vista (64-bit). Perhaps host system and QEMU binaries are relevant here. I will try on Linux host system later tonight. BTW, here are my images: http://mateusz.loskot.net/tmp/qemu/The problem was with NaN handling in fcmped instruction. I've committed a patch that fixes the problem, please test. Thanks for reporting and the test case.FYI, this problem seems to be occurring in qemu on Windows only. I tested git version dated before you applied the fix and built on Linux and the problem does not happening there.No, it was generic problem. I could reproduce it with your test case and with a small assembler program which only used fcmped using user emulator.
Booting an ss5-170 with a real sun ROM image still fails FP tests: 4.1.1 fpu reg regfile Pass 4.1.2 fpu reg misalign Pass 4.1.3 fpu reg single precision Pass 4.1.4 fpu reg double precision Pass 4.2.1 fpu exceptions single precision Failed Exception Didn't Block Store : 0 : exp= 00000000, obs= FFFFFFFF 4.2.2 fpu exceptions double precision Failed Exception Didn't Block Store : 0 : exp= 00000000, obs= FFFFFFFF
[Prev in Thread] | Current Thread | [Next in Thread] |