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

[Artyom Tarasenko]

On Sat, Jan 22, 2011 at 5:45 PM, Robert Reif <address@hidden> wrote:
> Blue Swirl wrote:
>>
>> 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
>>>>>> 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:
>>>>>
>>>>> 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.
>>
>>
>>
>
> 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/