On Sat, Jan 22, 2011 at 5:45 PM, Robert Reif <r...@earthlink.net> wrote: > Blue Swirl wrote: >> >> On Sat, Jan 22, 2011 at 3:30 PM, Mateusz Loskot<mate...@loskot.net> >> wrote: >> >>> >>> On 18/01/11 21:51, Blue Swirl wrote: >>> >>>> >>>> On Tue, Jan 18, 2011 at 6:00 PM, Mateusz Loskot<mate...@loskot.net> >>>> wrote: >>>> >>>>> >>>>> On 18/01/11 17:36, Blue Swirl wrote: >>>>> >>>>>> >>>>>> On Tue, Jan 18, 2011 at 3:27 PM, Mateusz Loskot<mate...@loskot.net> >>>>>> 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 >>>>>> nan >>>>>> >>>>> >>>>> I 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: >>>>> >>>>> mloskot@qemu-netbsd-50-sparc:~/tmp# ./a.out >>>>> is a number >>>>> nan >>>>> mloskot@qemu-netbsd-50-sparc:~/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. >> >> >> > > There is still a floating point exception problem that may or may not be > related.
AFAICS they are not related. Strictly speaking they are not FP problems but deferred trap processing problems. > 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 > > > -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
