Re: [Qemu-devel] [sparc] Floating point exception issue

[Robert Reif <reif@earthlink.net>]

Blue Swirl wrote:
> On Sat, Jan 22, 2011 at 3:30 PM, Mateusz Loskot<mateusz@loskot.net>  wrote:
>    
>> On 18/01/11 21:51, Blue Swirl wrote:
>>      
>>> On Tue, Jan 18, 2011 at 6:00 PM, Mateusz Loskot<mateusz@loskot.net>  wrote:
>>>        
>>>> On 18/01/11 17:36, Blue Swirl wrote:
>>>>          
>>>>> On Tue, Jan 18, 2011 at 3:27 PM, Mateusz Loskot<mateusz@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.

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