From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48010 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PgfQX-0000AV-GX for qemu-devel@nongnu.org; Sat, 22 Jan 2011 10:30:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PgfQU-0002xt-JF for qemu-devel@nongnu.org; Sat, 22 Jan 2011 10:30:57 -0500 Received: from srv1.whshost.com ([174.121.90.50]:50403) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PgfQU-0002xh-Eh for qemu-devel@nongnu.org; Sat, 22 Jan 2011 10:30:54 -0500 Message-ID: <4D3AF825.1020104@loskot.net> Date: Sat, 22 Jan 2011 15:30:45 +0000 From: Mateusz Loskot MIME-Version: 1.0 Subject: Re: [Qemu-devel] [sparc] Floating point exception issue References: <4D35B148.9080003@loskot.net> <4D35D542.5010608@loskot.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org On 18/01/11 21:51, Blue Swirl wrote: > On Tue, Jan 18, 2011 at 6:00 PM, Mateusz Loskot wrote: >> On 18/01/11 17:36, Blue Swirl wrote: >>> >>> On Tue, Jan 18, 2011 at 3:27 PM, Mateusz Loskot >>> 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 >>>> #include >>>> #include >>>> #include >>>> >>>> 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. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org